There's still a *lot* of code in there; > 26,000 lines in fact.
Whereas device-mapper weighs in at ~2,600 lines. This is just because
you've decided to take a different route from us, you may be proven to
be correct.
> > whereas we've taken the opposite route
> >and stripped down the kernel side to just provide services.
>
> Then why does snapshot.c in device mapper have a read_metadata function
> which populates the exception table from on disk metadata? Seems like you
> agree with us that having metadata knowledge in the kernel is a GOOD thing.
In the case of snapshots the exception data has to be written by the
kernel for performance reasons, as you know. This is still a far cry
from understanding the LVM1 metadata format.
> Since device_mapper does not support in kernel discovery, and EVMS relies
> on this, it would be very difficult to change EVMS to use device_mapper.
So do the discovery on the EVMS side, and then pass the tables across
to device-mapper to activate the LV's.
> Why compete, come on over and help us :-)
I would like the two projects to help each other, but not to the point
where one group of people has to say 'you are completely right, we
will stop developing our project'. It's unlikely that either of us is
100% correct; but I do think device-mapper splits off a nice chunk of
services that is useful to *all* people who want to do volume
management. As such I see that as one area where we may eventually
work together.
Similarly I expect to be providing an *optional* kernel module for LVM
users who wish to do in kernel discovery of a root LV, so if the EVMS
team has managed to get a nice generic way of iterating block devices
etc. into the kernel, we would be able to take advantage of that.
Are you trying to break out functionality so it benefits other Linux
projects ? or is EVMS just one monolithic application embedded in the
kernel ?
- Joe
-
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/