Re: kernel inclusion planned?

"Also sprach Christian Kujau:"
> I'm not sure if I understand your "waypoints" correctly: to me "waypoints" 
> are essential to coordinate a task/tasks for a goal. And it's about 
> coordination, as you said. So clearly, yes: if somebody (you?) really 
> wants kernel-inclusion by merging both modules, the merging has to be 
> coordinated to get to the goal. major "waypoints" would be the usual

They wouldn't - that's what I'm saying. The waypoints would have to 
satisfy the three criteria I set out.

> 1) try to merge the code

Not a waypoint .. you can't "try", you must do, and achieve something
that works, thereby.  You cannot leave the code in a non-working state
at any stage, so "merge the code" doesn't get you to a waypoint.
Moreover, you can't leave the code in any old random working state. It
has to be a _better_ and a _more desirable_ working state.

Those were the three criteria I set out. Working. Better. More
desirable.

A waypoint would be something like:

  replace the automatic registration of the request_fn in the nbd init
  code with something done a bit later, by an overlying module that
  gives the module its "personality" (nbd or enbd) thereby.

> 2) generate and apply patch

Again, that's a part of a working process.

> 3) see how/what it breaks

It musn't break ..  it wouldn't be allowed near the kernel if it did!
Things that break are parts of an internal process and patches aren't
things that break things ..  they're a final rendition of a solution.
Yes, I can offer patches to Paul Clement that will get us to a waypoint
we have agreed upon, but it is the waypoint that has to be designed and
thought about, and the agreement of the maintainer sought for.

> 4) fix it
> 5) try again...
> 6) submit patch ;)
> 
> although I cannot assist in 1) or 4), this is no rocket-science, IMHO. If 
> only I had the coding skillz...
> 
> > 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).
> 
> well, the "new, unified e/nbd module" probably *will* break one box or 

The problem is thinking of a way to get there. I.e. inventing the
waypoints.

> another. but bugs happen and with development in place, hardly to avoid.
> (as long as they get fixed ;))
> 
> > What would the modules be called? (just something practical that
> > springs to my mind as needing an answer :-).
> 
> % modprobe nbd enhanced=1
> 
> ...too simple?

Yes.  I would suggest that the base module be called gpbd (generic proxy
block device), and the modules on top be nbd and enbd.

But it would likely be easier to get agreement simply to load enbd on
top of nbd, so I guess that's moot!

> > 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.
> 
> Yes, makes sense. My ext2/ext3 analogy was not so good as it's an 
> exception.
> 
> > 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
> 
> well, this sounds not too bad :)
> 
> but again: I'm not requesting this, nobody else does, and if you don't 
> care - why bother? I only thought of it and it does seem easier to 
> maintain once it's in the kernel.

I do care. It's just a lot of effort. It's a lot easier not to bother!
Your prompting can make the difference.

Peter