Re: GSoC libchannel project draft

[Richard Braun]

On Fri, Mar 23, 2007 at 08:30:53PM +0100, Carl Fredrik Hammar wrote:
> Hello again!
> 
> I have finished writing a draft for the proposal I intend to submit to
> Google Summer of Code which I have appended to this mail and I would
> appreciate it if someone took their time to read it through.
> 
> Since the project could basically be summed up as ``libstore for
> character devices'', my main objective with the proposal is to show my
> current understanding of libstore but using terminology for channels
> ;-).  My understanding of libstore comes from extrapolating the
> information available in mailing list discussions and libstore's
> documentation and I might be on thin ice on some points.  While I can
> make up for mistakes in the proposal by commenting it after
> submission, I wouldn't want to submit any fundamental misconceptions
> on my part.
> 
> It has been recommended by some to include my CV into the proposal,
> but since I haven't written one and there isn't very much to put into
> it, I included some (hopefully) relevant information about myself
> directly into the proposal.  Will that do?
> 
> Any other wishes and suggestions are also welcomed!
> 
> 
> Fredrik

Hello,

There are two main points I want to discuss about.

First, in your example about pfinet (device-tunnel-pfinet), I don't see
the need for a single format. Such an abstraction could force the
implementation to ignore some important bits, just because the format
can't include them, and changing the common format would force us to
change all users of this format as well, even if it's not that much.
Changing just pfinet seems simpler to me, though not as extensible as
it could (and maybe should) be. In addition, the performance hit seems
really too much. But this concerns the design of pfinet, not libchannel,
so there is time to think about this.

The second and most important point you didn't mention in your proposal
concerns ioctls. Unlike block devices, there are lots of ioctls on
character devices, and unlike a common Unix like system, GNU Mach doesn't
handle ioctls. The problem here is that some ioctls expect a pointer
and a size, but the current ioctl() implementation is unable to know that
the parameter passed is a pointer and requires special handling. A kernel
has enough control to handle this once it gets the pointer, but in the
Hurd, the server can't do much with just a pointer and no data. The
current trick is to implement some hooks directly in the C library (such
as fioctl() in hurd/hurdioctl.c). Each "complex" ioctl must have such a
hook, and this is painful. Implementing libchannel could be the occasion
to find a generic solution to this problem.

On the other hand, this problem doesn't limit the Hurd's extensibility,
since ioctls are only required for compatibility, and any new interface
which is Hurd specific wouldn't use them, obviously. Anyway, even if
the current way is kept, you need some support at the libchannel side,
so think of it.

-- 
Richard Braun

signature.asc
Description: Digital signature