Re: GSoC libchannel project draft

[Carl Fredrik Hammar]

Richard Braun <syn@hurdfr.org> writes:

> 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.

I see your point.  Yes, maybe it would be best to have all supported
formats directly in pfinet.  However if a user wishes to use an
unsupported format it can still be converted to one of the supported
ones, this use-case would benefit from libchannel.  Though I'm
guessing this will be an uncommon practice in any case.

> 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.

Exactly.  But I think I'll drop the first part of the example and
stick with the part discussing balancing over two NICs, it's a more
interesting possibility anyway.

> 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

Ah!  I knew I was forgetting something!  Thanks a bunch for catching
this, I had given it some thought before but it didn't resurface while
writing the proposal.

This is something I want to be able to generically handle in the
library.  I'll see if I can manage to come up with a sketch to a
solution before the proposal dead-line, otherwise I'll put it as a
part of the project.

Thanks again!


Fredrik