mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Amit Choudhary <amit2030@yahoo.com>
To: Rene Herman <rene.herman@gmail.com>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: [DISCUSS] Making system calls more portable.
Date: Sun, 7 Jan 2007 01:07:41 -0800 (PST)	[thread overview]
Message-ID: <647618.57006.qm@web55614.mail.re4.yahoo.com> (raw)
In-Reply-To: <45A0AE5C.6010801@gmail.com>


--- Rene Herman <rene.herman@gmail.com> wrote:
>
>If we're limited to Linux kernels, this seems to not be the case. Great care is taken in keeping
>this userspace ABI stable -- new system calls are given new numbers. Old system calls may
>disappear (after a long grace period) but even then I don't believe the number is ever recycled.
>
> If your discussion is not limited to Linux kernels, then sure, but being 
> portable at that (sub-libc) level is asking too much.
> 

I will come to the main issue later but I just wanted to point out that we maintain information at
two separate places - mapping between the name and the number in user space and kernel space.
Shouldn't this duplication be removed.

Now, let's say a vendor has linux_kernel_version_1 that has 300 system calls. The vendor needs to
give some extra functionality to its customers and the way chosen is to implement new system call.
 The new system call number is 301. The customer gets this custom kernel and uses number 301.
Next, he downloads another kernel (newer linux kernel version) on his system that has already
implemented the system call numbered 301. The customer now runs his program. Even if he compiles
it again he has the old header files, so that does not make a difference.

Now his program uses number 301 that refers to some other system call and so, we can see system
crash, or some very wrong behaviour. Making system calls more portable will ensure that atleast
the program gets an indication that something is wrong (error returned from the kernel that this
system call name is not matched). Or, if the vendor is actually successful in pushing its system
call to the mainline kernel, no one needs to worry about it. Everything will run happily.

However, people may say that, implementing custom system calls is not advocated by linux. And I
think it is not advocated precisely because of this reason that they are not portable.

Regards,
Amit



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

  reply	other threads:[~2007-01-07  9:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-07  8:15 Amit Choudhary
2007-01-07  8:25 ` Rene Herman
2007-01-07  9:07   ` Amit Choudhary [this message]
2007-01-07  9:16     ` Rene Herman
2007-01-07 11:03     ` Jan Engelhardt
2007-01-07 13:59     ` Theodore Tso
2007-01-07  9:33 ` Vadim Lobanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=647618.57006.qm@web55614.mail.re4.yahoo.com \
    --to=amit2030@yahoo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rene.herman@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome