Re: Syscall Multiplexing

On 2003-10-01 at 02:46:43 [+0200], Axel D=F6rfler wrote:
> Ingo Weinhold <bonefish-CFLBMwTPW48UNGrzBIF7/[email protected]> wrote:
> > On 2003-09-30 at 01:24:35 [+0200], Axel D=F6rfler 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.
>=20
> >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 th=
e=20
implementation into two functions; the user_* function can contain the=20
actual implementation as well. Hence only half of the functions to mainta=
in.

> > > 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.
>=20
> Why do you think it has to be demultiplexed internally again?

For the syscalls for the actual operations (move, resize,...) there's no=20
question, since the DDM carries out these operations (on the shadow=20
partitions), not the modules.=20

That leaves the _kern_supports_*() and _kern_validate_*() calls. Of the=20
latter type exist only seven, all just invoking reusable functions (as=20
mentioned in my last mail), which one probably doesn't want to multiplex,=
=20
since their parameters are different enough, that invoking a multiplexed=20
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,=20
initialize). The simply-structured ones fall into two categories, one tha=
t=20
can be invoked for file systems (and therefore have a `whileMounted'=20
parameter) and those that can't.

So I'm not even sure, if we would do us a favor by multiplexing the=20
_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=20
make that much of a difference, I think. For clarity one would probably=20
dispatch to separate functions in the first case, anyway.

And not to implement a feature is very easy -- one just puts NULL into th=
e=20
slot for the respective hook. So, a read-only partitioning system like th=
e=20
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.
>=20
> 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