Re: Kernel deadlock using nbd over acenic driver

Steven Whitehouse (steve@gw.chygwyn.com)
Wed, 5 Jun 2002 09:48:05 +0100 (BST)


Hi,

>
> "Steven Whitehouse wrote:"
>
> (somethiung about kernel nbd)
>
> BTW, are you maintaining kernel nbd? If so, I'd like to propose
> some unifications that would make it possible to run either
> enbd or nbd daemons on the same driver, at least in a "compatibility
> mode".
>
No. My interest is just to help ensure that its working by sending
the occasional bug fix. Pavel Machek is officially in charge, so you'll
need to convince him of any changes.

> The starting point would be
>
> 1) make the over-the-wire data formats the same, which means
> enlarging kernel nbd's nbd_request and nbd_reply structs
> to match enbd's, or some compromise.
>
> 2) less important .. make the driver structs the same. enbd has more
> fields there too, for accounting purposes. That's the nbd_device struct.
>
> Later on one can add some cross-ioctls.
>
> Peter
>
I'm not so convinced that this is a good idea. I've always looked upon nbd
as the "as simple as possible" style of driver and its over the wire format
is good enough to cope with most things I think. Does enbd have a negotiation
sequence at start up like nbd ? Perhaps it would be possible to add some
code so a server could tell which type of client it was talking to ? I
think that would be simpler code changes and I'd be happier to see that kind
of change rather than any change to the over the wire format.

It would be nice to add a bit more accounting. We need also to dynamically
allocate the nbd driver structures because as they get larger its less
efficient to allocate them statically as we currently do. The question is
then when to free them. I think that probably the disconnect ioctl() could
provide a suitable hook for that,

Steve.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/