Richard Braun <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-hurd
