>EVMS differs from us in that they seem to be trying to move the whole
>application into the kernel,
No, not really. We only put in the kernel the things that make sense to be
in the kernel, discovery logic, ioctl support, I/O path. All configuration
is handled in user space.
> 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.
>This is fine, I think there's room for both projects. But it is worth
>noting that EVMS could be changed to use device-mapper for it's low
>level functionality. That way they could take advantage of the cool
>work we're doing with snapshots and pvmove, and we could take
>advantage of having more eyes on the core driver.
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.
Besides, EVMS already has all the capabilities provided by device mapper,
including a complete LVM1 compatibility package.
>LVM2 may not seem that exciting initially, since the first release is
>just concentrating on reproducing LVM1 functionality. But a lot of
>the reason for this rewrite is to enable us to add in the new features
>that we want (such as a transaction based disk format). It's on this
>new feature list that we'll be mainly competing with EVMS.
Why compete, come on over and help us :-)
Steve
EVMS Development - http://www.sf.net/projects/evms
Linux Technology Center - IBM Corporation
(512) 838-9763 EMAIL: SLPratt@US.IBM.COM
-
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/