I don't know if you remember me, but you bailed me out from some trouble I
had with LVM.... TWICE!
> I'm sorry you feel disappointed. But I assure you that EVMS will
> continue to provide the same experience you have come to expect. All
> this decision really means is that we will be building on a different
> kernel component, instead of providing our own. All of the EVMS tools
> and libraries will essentially be unchanged from the perspective of
> most users.
I've had some time to think about this. As a programmer, I am lothe to
re-invent any wheel that someone else already has. I think this may be how
you guys came to this decision.
> And we will still maintain that modular design. In fact, we see this
> as making the design even more modular, since it won't have to be tied
> to a single kernel driver. Device mapper can be used for supporting
> disk partitions, LVM, and some other plugins. The MD driver can be
> used to support software RAID. We've even had thoughts about building
> on the existing loop driver in order to provide the partition-level
> encryption that you mentioned. And all of this from a single, unified
> interface.
It's beginning to sound like you may be able to leverage the work that went
into MD and LVM and consentrate on (perhapse) some really cool stuff, like
partition-level encyption, or the disk partitioning scheme involving RAID,
NBD's and LVM that Alan Cox outlined in another post.
> > But never mind me. I'm just a linux user, not a linux developer.
>
> Actually, it *is* the users that we are most concerned with. This is
> why we are going to make such an effort to keep our tools as unchanged
> as possible. But we really do think that this is the best solution in
> the long term, for both the users and the developers.
As I said in a different post, that was a cheep shot on my part. I'm usually
much bigger than that.
So, let me try to understand. The EVMS team is going to rip out the guts of
their user-land utils in order to comply with the existing (mainstream) API,
and abandon their own API. This should reduce the amount of code actually in
the kernel. (ignoring the user-land v. kernel-level discovery debate)
Na, I can't ignore the debate. I can't wait to see how user-land descovery
will be implemented. There is something intrinsically "nice" about having an
OS automatically discover every aspect of a machine I'm installing on. I
guess it's going to fall to the Linux distributors to package this system
well. If they don't, first-time Mandrake or RH installers will be doomed to
that (shudder) other operating system.
> If you continue to have any concerns about this, please let us know.
> We will do our best to address them and explain any other details
> about this change that you are unsure of.
I'll just have to wait. BTW, Kevin, if you are ever in Albuquerque, NM. let
me know; I still owe you a beer. <grin>
-- Mike Diehl PGP Encrypted E-mail preferred. Public Key via: http://dominion.dyndns.org/~mdiehl/mdiehl.asc- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/