Re: kernel inclusion planned?

"Also sprach Christian Kujau:"
> On Thu, 15 Jun 2006, Peter T. Breuer wrote:
> > I want to answer this, but it's late. Maybe this answer will spill over
> > a few days.
> 
> ...and yet you answered this very much in detail :)

No so much :-(.  I am hampered by article deadlines and conference
talks and so on (and the football on TV has nothing to do with it,
clearly).

> > The problem is "how exactly do you do that". A roadmap is a way of
> > getting from A to B, and that means inventing waypoints that are
> > not only just points, but meaningful in themselves, in that they
> > represent
> >
> >  1) something that works
> >  2) something that makes things better than they are now
> >  3) something that achieves a desirable goal
> 
> both nbd and enbd are working pretty well I think.

The word that I should have emphasised more there is "waypoints". To
get from A to B, one has to pass through waypoints A1 A2 A3 A4 ... and
it is THOSE that must individually satisfy each of the points 1-3 I gave
above.

I suggested making the in-kernel nbd driver grow a hook (a method) to
implement its driver cycle as a personality.  As I recall, all the work
in the nbd driver is done in its request_fn.  The client merely calls
in via an ioctl to pass down the socket for the connection, and the
client gets stuck there.  The driver then carries on on its own, using
the handed-down socket in a continuous drive cycle.  One could add
trivial code in the nbd driver

    register_request_fn()
    unregister_request_fn()

which has the duty of registering the nbd driver's request_fn (the drive
cycle) with the kernel "on demand", rather than have the kernel
registration compiled into the nbd init code, as it is now.

That would allow different driver personalities to be assumed according
to what argument (address of function) was supplied as argument to a
register_request_fn() call, perhaps via an additional module loaded on
top of the nbd module.  Then one could start seeing what bits of the nbd
driver can be reused for enbd.


> I'm not sure if the 
> only way to get enbd in the kernel would be to unify both to one driver if 
> it has mutually exclusive features. The ext2/ext3 FS comes to mind: both 
> very similiar, but still seperated.
> 
> 1) involves bugfixing the problems the merging of the code would bring

My point was that one needs to construct practical waypoints. These
have to be very concrete.

> 2) is the in-kernel option to choose wether to use nbd or enbd (wether
>     it's a .config option or a module parameter to choose from)

I simply suggest that the enbd module be loaded on top of nbd, in order
to give it a different personality. But that's a goal, not a waypoint.
I reemphasise that waypoints have to be very very concrete, and satisfy
the criteria I tried to set out .. essentially, they must be working
code, and code that brings immediate benefit (or at least does no
harm).

> The aim would be to choose enbd or nbd funtionality without patching, IOW: 
> more-features-for-lazy admins :)

What would the modules be called? (just something practical that
springs to my mind as needing an answer :-).

> Peter, I see now that there is major surgery involved in merging them both 

Not so much, the way I suggested. The problem is that it requires
coordination.

A long time ago I asked Linus if he would take the enbd module and he
replied that he would prefer to see mods made to the nbd module to 
unify them. I understand that. I know Paul Clement, the current kernel
nbd maintainer (or was, last time I looked) and can talk to him. The
initial change I suggested above would be only a few lines of patch,
and would have absolutely no impact on current nbd functionality. Yet
it would open the way for enbd to be implemented on top of nbd. I might
suggest it to him.


Peter