Re: Opencomm: proplib-based syscall

[Elad Efrat <elad%NetBSD.org@localhost>]

On Sun, Apr 26, 2009 at 11:26 PM, Thor Lancelot Simon 
<tls%rek.tjls.com@localhost> wrote:

>> The /dev/drvctl node could use this instead of needing a filesystem hook -
>> as far as I recall it is an ioctl-only node that passes plists, nothing
>> performance critical. Ditto for /dev/bthub which could be merged and I'm
>> sure there are others I don't know about.
>
> Why is this desirable?  I cannot see going the plan9 way and making the
> filesystem namespace and permissions the _only_ kernel-user namespace and
> permissions -- but I also see little or no point to discarding existing
> uses of the filesystem namespace where they are convenient and simple.
>
> We have ioctl-only device nodes in a number of places where older Unices
> (including older NetBSD) had special-purpose system calls.  They offer
> some very useful advantages, like reference (and per-user state) tracking
> via the generic file and file descriptor handling code in the kernel, and
> the ability to simply use chown and chmod for access control.

Let's say you want to have access control for "drvctl" and you're
approaching to implement it. What are your options besides using a
pseudo device so you can chown/chmod it?

> What advantage is there to undoing this and using special-purpose
> syscalls all over the place, whether those syscalls' arguments are passed
> as XML or something else?

I don't think anyone's suggesting undoing things and using
"special-purpose syscalls all over the place". What I'm suggesting is a
single syscall that is general-purpose and having it as an additional
option, an alternative. That's quite different. :)

-e.