Re: Syscall Multiplexing

On 2003-09-30 at 01:24:35 [+0200], Axel D=F6rfler wrote:
> Tyler Dauwalder <tyler-cyCl/[email protected]> wrote:
> > Ingo mentioned last week that you, Axel, were interested in us
> > multiplexing
> > some of the ddm syscalls, since it's a bit of a chore to add the
> > syscalls
> > to the kernel. I offered to tackle the task, but I wanted to ask
> > first what
> > exactly is involved in adding syscalls to the kernel. It looks to me
> > like
> > you have to add the symbolic constant to headers/private/kernel/
> > ksyscalls.h
> > and an appropriate dispatch case to src/kernel/core/syscalls.c. Am I
> > missing anything else?
>=20
> Yes, you have add:
> 1) prototypes for the _kern_ and _user_ calls
> 2) add the syscalls to kernel/libroot/os/syscalls.S (with the syscall
> number and the 32-bit argument count (64 bits are counting twice))
> 3) do what you said
> 4) implement the userland part of the syscall (those who call the
> _kern_*() calls, which could be used from both, the kernel and
> userland)

I believe none of the _kern_*() functions will be needed from the kernel.=
=20
As you might have seen, I pulled most (even all?) of the validate_*()=20
helper functions out of the file and made them available to the rest of D=
DM=20
implementation (mainly for the implementation of the jobs, which will onc=
e=20
again do a check before giving over the control to the modules). There's =
a=20
certain chance, that those functions will moved into a class with a more=20
pleasant interface, BTW.

> > In lieu of multiplexing our ddm syscalls, I thought maybe I would
> > just
> > offer to add the syscalls themselves to the kernel rather than having
> > you
> > do it. Unless I've missed some terribly time consuming step in the
> > syscall
> > addition process, it seems to me it's just going to be more work
> > overall to
> > multiplex them, and the additional code, IMO, just leaves more room
> > for
> > error.
>=20
> I actually never thought of demultiplexing them - I thought of less
> functions for the user, less syscalls, and most important, less
> functions to implement for the module programmer :-)

I'm a bit afraid, that internally the calls need to be demultiplexed=20
anyway, so that it would be multiplexing in userland, demultiplexing in t=
he=20
syscall and multiplexing again for the modules. Not sure though. This nee=
ds=20
a bit of investigation.

BTW, what is nice about having a non-multiplexed module interface, is tha=
t=20
there it is easier to decide, whether a module doesn't implement a hook o=
r=20
whether a request really fails due to some error.

CU, Ingo