linux-kernel - Re: Re: Idea: Feature information / extensions dispatcher syscall.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 Apr 2009 18:46:56 +0400
From:	Igor Zhbanov <izh1979@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: Re: Idea: Feature information / extensions dispatcher syscall.

2009/4/22 Andi Kleen <andi@...stfloor.org>:
> Igor Zhbanov <izh1979@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/