tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Opencomm: proplib-based syscall
On Tue, Apr 28, 2009 at 10:19 PM, Andrew Doran <ad%netbsd.org@localhost> wrote:
> Sorry but I don't like this either.
>
> - It's a new name space and a new channel when we already have reasonable
> ones in place.
I disagree. The file-system namespace is limited to the traditional
Unix permission bits when setting access control. The sysctl namespace
is a mess on that aspect as well (unless you want to introduce a
handler for each node). The syscall namespace is numbers, it's not
really a "namespace".
> - Performance wise it will suck, enough to make it useful only for out of
> band stuff.
I don't believe you'll be able to measure a meaningful performance
impact with the major uses I have for it in mind. :)
> - The generality of what you propose concerns me, for example being able
> to call arbitrary functions.
It was just an idea, we can simply not implement it...
> - In cases where we do want things to be more flexible we can pass in a prop
> turd with a syscall/write/ioctl/whatever AND be careful to design
> interfaces that do not have stupid compat or extensibility issues. The
> classic disaster area example here is of course the mount() syscall.
Like I said above, this limits you to the access control provided by
those interfaces.
For example, almost everything tunable under sysctl currently falls
under a single authorization check. If we want to extent that, we
obviously have to extend sysctl. What did you do when approached to
fix NetBSD's threading? :)
But anyway, I guess we can come back to this topic when I'm done with
the more important issues. Maybe by then I'll have a different
opinion/idea... ;)
Thanks,
-e.
Home |
Main Index |
Thread Index |
Old Index