Re: kernel inclusion planned?

"Also sprach Christian Kujau:"
> On Wed, 14 Jun 2006, Peter T. Breuer wrote:
> > There's no way to "plan" such a thing. THere would have to bve a
> > roadmap ...  the only roadmap that I can see is via unification of the
> > nbd and enbd protocols.
> 
> Hm, and this ain't gonna happen?

I want to answer this, but it's late. Maybe this answer will spill over
a few days.

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

2 does not necessarily imply 3. For example, restructuring a driver
completely may make things better in many ways, but if there isn't
a concrete aim in mind, nobody will do it and they would be right.

I suggested that the first waypoint might involve some unification
of the nbd and enbd protocols. One must work on the nbd driver, since
it is in the kernel, and do something to it. What? What (1) will
we get? Maybe

   1) an nbd driver and client that works with the existing enbd
   server, if a few mods are made to the latter in preparation,
   and if one accepts "working" as a very very primitive mode.

But does it get one a (2)? Well, if I could avoid actually doing harm
to the kernel nbd driver functionality, I could maybe argue that the
damage to the code is sustainable, given a suitable (3).

   2) doesn't actually make functionality worse and has minimal impact
   on code clarity. Maybe it could be done as a hook that allows
   different protocols to be levered into nbd, which might allow some
   clarity.

What is (3)? Maybe

   3) allows different personalities to be run in the nbd code, such
   as enbd.

However, there are big problems in doing any of this. The nbd client
works by handshaking in userspace, then hands the socket over to the
kernel to talk on. The enbd client has a separate control channel on
which it talks, and then it pokes into the kernel from time to time 
with the results of its own networking transactions, on a different
channel to the control channel.

The nbd driver runs a complete cycle including networking in the
kernel. The enbd driver merely places info where the enbd client
can read and write to it, and works in tandem with the client.

The nbd driver might be able to handle an entire enbd cycle in kernel if
I added code to it that allowed the cycle handler to be loaded as a
personality. But it would need the enbd client to work with an enbd
server. That's not so bad.

That might be a first step.



Peter