On 10/13/02 23:35, Christoph Hellwig wrote:
> _I_ don't want to get EVMS in, sorry.
You've made your intentions crystal clear. Lucky you're not the
one you decides. At the end of the day it is just another 'driver'
and I don't think it's fair to place a higher benchmark of quality
on EVMS than all the other drivers in the kernel (although your
criticism does serve as a good way of disguising your motives of
blocking its inclusion).
We all know you 'you can't please all of the people all of the time'
and its always the dissenters who have the loudest voice.
> I _do_ want a proper volume managment framework, but I can live with
> it not beeing in before 2.8.
Some of us have large arrays and SANs where the absence a volume
manager is a big thing. I'm glad to see the distros picking it up
- i guess they have customers who need this sort of stuff.
How about feedback from other kernel developers on EVMS. Does anyone
think 'its good enough for inclusion now as long as a few cleanups
are done after the freeze'?
~mc
On Mon, 14 Oct 2002, Michael Clark wrote:
> Some of us have large arrays and SANs where the absence a volume
> manager is a big thing. I'm glad to see the distros picking it up
> - i guess they have customers who need this sort of stuff.
>
> How about feedback from other kernel developers on EVMS. Does anyone
> think 'its good enough for inclusion now as long as a few cleanups
> are done after the freeze'?
Mostly those who won't have to clean up the mess afterwards.
For the record, my vote is "not ready".
There are good chunks, no arguments about that. However, IMNSHO
we will be better off if we gradually pick the pieces that make sense
and integrate them into the system. As it is, wholesale merge would cost
us too much half a year down the road.
I have seen major subsystem rewrites. I have done several myself.
I have also done more than a bit of wading through "yet another drivers".
EVMS in its current state shows a lot of signs promising very painful
work on cleanups and intergration. "Few cleanups after the freeze" doesn't
come anywhere near the impression I'm getting from it and I would bet a lot
on that particular impression.
On 10/13, Alexander Viro said something like:
> Mostly those who won't have to clean up the mess afterwards.
> For the record, my vote is "not ready".
Oh shit! This is the "Al Viro stink test" Linus spoke of.
Now, if no LVM type ifrastructure is included in 2.6, all (all who use an
LVM of some type) will all have to
1. update to the latest mainline
2. download the latest dm or evms patch
3. fix all the patch rejects themselves (big problem to overcome when
trying to get people to test with the latest kernel)
I'm NOT saying this is some kind of argument toward inclusion. I guess
I'm just lamenting. I really hoped I'd have one less 3rd party patch to
maintain in my own personal tree.
--
Shawn Leas
[email protected]
I was in the first submarine. Instead of a periscope, they had
a kaleidoscope. "We're surrounded."
-- Stephen Wright
On Mon, Oct 14, 2002 at 12:18:52AM +0800, Michael Clark wrote:
> one you decides. At the end of the day it is just another 'driver'
> and I don't think it's fair to place a higher benchmark of quality
> on EVMS than all the other drivers in the kernel
If you followed lkml you'll see that I even explain authors of
very small drivers how to fit the kernel standards. The situation
with those is a little different as they are not a framework and
don't add new APIs. Thus it's only a correctness and style issues.
EVMS on the other hand is not only a lot of code but also a framework,
i.e. it folows certain design principles. And I fundamentally
disagree with some of those.
> Some of us have large arrays and SANs where the absence a volume
> manager is a big thing.
Not having EVMS ~= not having a volume manager. I don't want
to have to manage my storage farms without a volume manager either,
but that doesn't have to mean that I like the EVMS design.