[openbeosstorage] Re: Syscall Multiplexing
- From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
- To: openbeosstorage@xxxxxxxxxxxxx
- Date: Thu, 02 Oct 2003 01:49:01 +0200 CEST
Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx> wrote:
> > 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.
That's only partially right as the actual implemention would be almost
the same, as in
do_work
{
a = a + 1;
}
_user_do_work
{
prepare a;
do_work;
}
compared to:
_user_do_work
{
prepare a;
a = a + 1;
}
Although that's of course the perfect example :-)
> > 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.
That all sounds as if we should try to not to multiplex them first :-)
> > 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. :-)
Have fun :-))
Bye,
Axel.
Other related posts:
