Idea: Feature information / extensions dispatcher syscall.

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?

Re: Idea: Feature information / extensions dispatcher syscall.

[Andi Kleen]

Igor Zhbanov <izh1979@gmail.com> writes:
>
> 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?

You're trying to reinvent the vfs / device nodes / ioctls

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: Re: Idea: Feature information / extensions dispatcher syscall.

[Igor Zhbanov]

2009/4/22 Andi Kleen <andi@firstfloor.org>:
> Igor Zhbanov <izh1979@gmail.com> writes:
>>
>> 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?
>
> You're trying to reinvent the vfs / device nodes / ioctls

Perhaps.
But in some cases syscalls are more convenient than reading/writing/ioctling
in /proc, /sys or /dev.

Now as I understand creating new syscalls for "home" use is not encourahed.
It is not guaranteed that tomorrow new syscall will not be introduced
in mainstream kernel. So portability issues is not considered for
"home" modules.

And I suggest to regulate syscalls usage and reserve a set of numbers
"home" modules used in some organizations only.

I don't think that they all will use only devices and /proc and /sys
to communicate
with their modules.

Re: Idea: Feature information / extensions dispatcher syscall.

[Igor Zhbanov]

Is it bad that modules will dynamically register/unregister their syscalls
and libraries will ask numbers via standardized interface?

Re: Idea: Feature information / extensions dispatcher syscall.

[Alan Cox]

> But in some cases syscalls are more convenient than reading/writing/ioctling
> in /proc, /sys or /dev.

A syscall and an ioctl are the same thing except that you need a file
handle for one of them.

> And I suggest to regulate syscalls usage and reserve a set of numbers
> "home" modules used in some organizations only.

We have file system naming so you can open device or sysfs and the like
files to do that job. That avoids the problem of trying to keep numbering
sane.

Alan

--
	"Alan, I'm getting a bit worried about you."
				-- Linus Torvalds

Re: Idea: Feature information / extensions dispatcher syscall.

[Igor Zhbanov]

2009/4/22 Alan Cox <alan@lxorguk.ukuu.org.uk>:
>> But in some cases syscalls are more convenient than reading/writing/ioctling
>> in /proc, /sys or /dev.
>
> A syscall and an ioctl are the same thing except that you need a file
> handle for one of them.
>
>> And I suggest to regulate syscalls usage and reserve a set of numbers
>> "home" modules used in some organizations only.
>
> We have file system naming so you can open device or sysfs and the like
> files to do that job. That avoids the problem of trying to keep numbering
> sane.

Yes, you need a file handle. To open device each time you need to make ioctl
is expensive and keeping device opened may prevent unmounting /proc
that could be a problem in some installations if that application is used
at a boot time.

Re: Idea: Feature information / extensions dispatcher syscall.

[Alan Cox]

> Yes, you need a file handle. To open device each time you need to make ioctl
> is expensive and keeping device opened may prevent unmounting /proc
> that could be a problem in some installations if that application is used
> at a boot time.

- Nobody in the real world unmounts /proc.
- You don't need to use /proc anyway
- You don't need to open the device each ioctl
- Even if you did open is extremely quick