tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Opencomm: proplib-based syscall



On Sun, Apr 26, 2009 at 08:19:22AM +0300, Elad Efrat wrote:
> 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.

And, what does this buy you over passing arguments? Nothing besides
compat headaches and new ways to create compat problems.

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

They'd still need to do all the same work, just with whatever
slots/hooks your new stuff uses instead of syscall slots, and at the
user end you have to write a pile of crap to do proplib-based argument
marshalling instead of normal argument passing.

Using proplib doesn't magically solve any of the problems with
handling interfaces; it just moves them around, and in the process
makes things big and unwieldy.

> I think having a syscall that can provide interface to all syscalls,
> including the versioned ones, using names (see separate discussion on
> the dictionary format) can make automated testing a lot easier here --
> to elaborate on the xmlif idea, you can also autogenerate dictionaries
> that stress test syscalls using various argument combinations (once
> you have a specification that says what type an argument is and an
> interface to set values easily into an "argument package", you can
> easily write value generators -- but you get the idea I guess. :)

You can do this just as easily with ordinary system calls. And in
fact, it's a lot easier that way. I wrote something of the sort for
OS/161 years ago.


...overall, I don't see the point.

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index