Idea: Feature information / extensions dispatcher syscall.

[Igor Zhbanov]

Hello!

System calls is a very convenient way to talk to modules. But when some modules
used locally (e.g. in one organization only) it will be to impractical
to reserve system
call number in linux kernel source for that feature forever. Usually
first free syscall
number is used. But when new system call is introduced in official kernel,
one need to rewrite all modules and libraries, since first free
syscall number is increased.

I suggest to reserve one system call to provide information about
other system calls.
This can help to build system call independent programs.

That informational / dispatcher system call can take some identifier
as argument (e.g. GUID)
and return some information about asked extension (e.g. syscall number
for that extension).

So libraries that use some additional functionality upon first call of
extension function
will ask kernel (via informational syscall), what is the number of
feature's syscall, and will
use it later directly.

Also can be useful to reserve some system call number (e.g. 8) for
such extensions,
so extension modules can use first unused number of this set.

This allow to use system calls in any extension modules without need to reserve
syscall number in kernel source and allow binaries to run correctly on
any kernel
(where that extension feature can have another syscall number).

What do you think?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/