Re: kernel inclusion planned?

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 :)

> 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. 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
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)
3) hm, this is a combination of 1+2, IMHO.

> 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.

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

> 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).

yes, stability should not suffer, of course. but 2.6 is in development 
anyway and there's always -mm to play around.

[good stuff snipped]

> 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.

Peter, I see now that there is major surgery involved in merging them both 
togeter and I really appreciate your comments on this but I did not intend 
to "request" this or so: it was meant as a mere "has it been discussed at 
all" question, because I could not find anything related to "kernel 
inclusion" in the archives and wondered at which point it was necessary to 
develop enbd at all without discusssing with the nbd folks if nbd could be 
"enhanced". Obviously, it was necessary and I'm glad that enbd is 
maintained (and supported too!) so very well.

So, please don't get into this too much/at all, if no-one really cares 
about inclusion. (I really only wanted to know if it's discussed).

However, I *could* imagine that maintaining this thingy could be easier 
after it's in mainline, because you have the whole lkml-folks looking at 
code/bugs/patches and the userbase would be larger and since you're 
maitaining the driver pretty much alone (not?) your workload might 
decrease...makes sense?

Thanks for the details,
Christian.
-- 
BOFH excuse #196:

Me no internet, only janitor, me just wax floors.