[openbeosstorage] Re: Syscall Multiplexing
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Tue, 30 Sep 2003 23:47:50 +0200
On 2003-09-30 at 01:24:35 [+0200], Axel Dörfler wrote:
> Tyler Dauwalder <tyler@xxxxxxxxxxxxx> 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?
>
> 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.
As you might have seen, I pulled most (even all?) of the validate_*()
helper functions out of the file and made them available to the rest of DDM
implementation (mainly for the implementation of the jobs, which will once
again do a check before giving over the control to the modules). There's a
certain chance, that those functions will moved into a class with a more
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.
>
> 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
anyway, so that it would be multiplexing in userland, demultiplexing in the
syscall and multiplexing again for the modules. Not sure though. This needs
a bit of investigation.
BTW, what is nice about having a non-multiplexed module interface, is that
there it is easier to decide, whether a module doesn't implement a hook or
whether a request really fails due to some error.
CU, Ingo
Other related posts:
