[openbeosstorage] Re: Syscall Multiplexing
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Wed, 01 Oct 2003 22:18:42 +0200
On 2003-10-01 at 02:46:43 [+0200], Axel Dörfler wrote:
> Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > On 2003-09-30 at 01:24:35 [+0200], Axel Dörfler wrote:
> > > 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.
>
> >From the POV of a syscall, it doesn't make a difference (effort-wise)
> if an API is only available to userland or not. That's the whole point
> behind the story :)
If the kernel doesn't use the syscall, then you don't need to split up the
implementation into two functions; the user_* function can contain the
actual implementation as well. Hence only half of the functions to maintain.
> > > 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.
>
> Why do you think it has to be demultiplexed internally again?
For the syscalls for the actual operations (move, resize,...) there's no
question, since the DDM carries out these operations (on the shadow
partitions), not the modules.
That leaves the _kern_supports_*() and _kern_validate_*() calls. Of the
latter type exist only seven, all just invoking reusable functions (as
mentioned in my last mail), which one probably doesn't want to multiplex,
since their parameters are different enough, that invoking a multiplexed
version would be very ugly.
Several of the _kern_supports_*() style syscalls are indeed of the form:
<preamble>
...
return diskSystem->SupportsXYZ(partition[,...]);
But others require specific checking (like the ones for resize, move,
initialize). The simply-structured ones fall into two categories, one that
can be invoked for file systems (and therefore have a `whileMounted'
parameter) and those that can't.
So I'm not even sure, if we would do us a favor by multiplexing the
_kern_supports_*() calls.
> Or do you mean the final implementation in the module? In this case,
> you'd be right, although it would be less write effort to implement
> them :)
Whether I write ten functions or just one with a gigantic switch doesn't
make that much of a difference, I think. For clarity one would probably
dispatch to separate functions in the first case, anyway.
And not to implement a feature is very easy -- one just puts NULL into the
slot for the respective hook. So, a read-only partitioning system like the
one for CD sessions will implement only a handful of standard hooks.
> > 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.
>
> Well, just go on and implement the full intel partitioning system - if
> you then still think that it doesn't have to be multiplexed, then lets
> go for it :-)
Will do. :-)
CU, Ingo
Other related posts:
