[openbeosstorage] Re: Syscall Multiplexing

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: