Re: [DISCUSS] Making system calls more portable.

[Theodore Tso <tytso@mit.edu>]

On Sun, Jan 07, 2007 at 01:07:41AM -0800, Amit Choudhary wrote: 
> 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.

So the vendor is doing something bad, and his customers will pay the
price, and they will switch to another vendor who isn't doesn't create
traps for their customers.   What's the problem?  :-)

Serious,y you got into trouble in your second sentence --- and not
just by the use of the passive voice: "the way chosen is to implement
(a) new system call".  Don't do that.

There are plenty of other ways of requesting kernel services; you can
create your own device driver and pass string commands to the device
driver, for example.  What?  You say string-based parsing is slow?
But you were just advocating doing that for all system calls!

Well, then your other choice is to convince the kernel developers that
the interface is stable, and of general interest to the community ---
and if not, then perhaps a more general version of the interface can
be made, with peer review improving the design, and then that can get
implemented.

One example (of both strategies) is shared namespaces.  A vendor's
engineers worked with the Linux VFS developers to introduce shared
namespaces, so that in the future an important product of theirs will
be able to use that feature, instead of a custom kernel module, which
was getting too expensive to maintain.  Getting shared namespaces in
took well over a year, and it'll probably another year or two before
all customers' systems will have it and the product can be revved to
use it, but that's an example of the right way to do things; and in
the meantime, customers are using the version that requires a binary
module that does *NOT* use system calls to provide kernel callouts,
but a custom filesystem instead.

						- Ted