Re: Opencomm: proplib-based syscall

[Andrew Doran <ad%netbsd.org@localhost>]

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.

- Performance wise it will suck, enough to make it useful only for out of
  band stuff.

- The generality of what you propose concerns me, for example being able
  to call arbitrary functions.

- 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.

On Sun, Apr 26, 2009 at 03:10:20AM +0300, Elad Efrat wrote:

> For a long time I've been thinking about implementing a proplib-based
> syscall -- I call it "opencomm" -- and only now got around to it.
> 
> It's like prop_dictionary_sendrecv_ioctl(), only that:
>    - it doesn't require a file-descriptor/command
>    - it takes a syscall slot
> 
> There are really tons of stuff we can do with it, and I think it opens
> the door to a lot of experimenting (and perhaps even lowers the bar).
> Some uses that come to mind:
> 
>   - We can basically implement any syscall on top of it (with a
>     performance impact, yes)
> 
>   - We can offer past and future ABI compatibility (think of
>     internalizing syscall arguments for mount() or whatever, so you
>     don't even have to rebuild the program)
> 
>   - Subsystems can register themselves with opencomm() instead of
>     adding a new syscall
> 
>   - Data passed to the kernel is not just a "struct" that might be
>     internal to NetBSD, and can be [sent on the wire to and] inspected
>     by other systems
> 
>   - We can invoke arbitrary kernel functions, maybe even sequences of
>     them, aggregate results, and return to userspace
> 
> I'm sure others can think of much more exotic uses. :)
> 
> The changes required to implement it are very small (copy/paste of
> prop_dictionary_sendrecv_ioctl in prop_kern.c, one line change to
> syscalls.master, and (for now) a stub in kern_xxx.c).
> 
> Are there any objections for it being added?
> 
> Thanks,
> 
> -e.