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