Re: Opencomm: proplib-based syscall

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Sun Apr 26 2009 at 08:19:22 +0300, Elad Efrat wrote:
> >>It's like prop_dictionary_sendrecv_ioctl(), only that:
> >>   - it doesn't require a file-descriptor/command
> >>   - it takes a syscall slot
> >
> >It should be implemented as RPC by read/write on a file descriptor.  By
> >plugging it into a proplib ioctl kludge you just destroy the generality.
> 
> There's no "ioctl kludge" in it, the ioctl() call in the userland part
> has been replaced with __syscall(), and the kernel only uses the ioctl
> wrappers for their copyin()/copyout(). Extract these out of proplib, and
> you won't see the word "ioctl" anywhere. :)

And you still don't have a read/write interface.  To make *your* "pass
over the wire to other systems" use case possible, you'd need to invent
an additional protocol.  Having your implementation and use cases not
match does not give a very good first impression.

> >>  - 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)
> >
> >Compatibility reduces to the same problem as with binary interfaces:
> >you still need to handle both cases, so you don't get any benefit here.
> >And if your old binary doesn't deliver the info that the new version of
> >the syscall wants, no amount of proplib can conjure up the missing data.
> 
> It really depends. The easiest case here is mount, as that's an example
> for a program that really comes down to a syscall. Control its arguments
> using dictionary internalizing from a file and you can always pass a
> file with some XML in it instead of arguments.

As I already pointed out, that does not magically solve all problems.
In fact, fundamentally it is completely the same thing as the current
model.  You can just as well pass uint8_t[] read from a file and have
the same problems and same responsibilities.

Say the argument is

struct {
        a;
        b;
}

And the relevant xml is <a></a><b></b>.  What needs to happen if you
need to add "c", change "a" or remove "b"?

Saying that opencomm will fix compatibility is like making a roux and
saying that we now have a generic sauce for all foods.
(n.b. this analogy has more than one level to it)

> >>  - Subsystems can register themselves with opencomm() instead of
> >>    adding a new syscall
> >
> >.. or they can just use syscall_establish().  Otherwise we would divide
> >syscall provides into two camps.
> 
> Using syscall_establish() they're risking taking up a slot that is used
> by someone else, no? they also require you to rebuild userland programs
> and provide a library interface for the syscall to be useful.
> 
> I'd like a vendor to be able to register a "syscall" without all the
> associated headache of trying to assign a syscall number (especially now
> that we still have syscalls.master), writing a library interface for it,
> etc.

1) you still need a scheme to avoid conflicts.  granted, it may be easier
   since you have more namespace.
2) there is no need to write a library interface even now.  syscall() is
   opencomm without xml.
3) i bet the vendors don't appreciate their performance-critical
   apps being forced to using proplib

Your answer didn't address my original concern related to "3" at all.

> >I'm not convinced that just providing
> >opencomm buys us anything if we don't do the rest of the work.
> 
> Obviously.

I'm still not convinced.  Actually, I'm less convinced now.  To me,
your current argumentation pretty much reads: "add a generic interface
which can be used for something".  Implement a useful use case and then
you have something concrete to shut me up with.