Re: Opencomm: proplib-based syscall

[Elad Efrat <elad%NetBSD.org@localhost>]

On Sun, Apr 26, 2009 at 11:19 AM, David Holland
<dholland-tech%netbsd.org@localhost> wrote:
> 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.

That's not the strongest point, but anyway: it buys me the option of not
rebuilding a program because I need to change arguments to a syscall.

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

The "new stuff" uses names, not slots.

At the user end you don't "have" to do anything unless you want to use
the new interface. It's a proposal for an alternative interface, not a
replacement.

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

Can you elaborate on how it moves the problems around?

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

I'd like to hear how it's easier. I'm willing to argue that being able
to generate syscall calls and their arguments in runtime is a big
advantage.

-e.