On 2002-10-12 13:32:33, Christoph Hellwig wrote:
> > On Fri, Oct 11, 2002 at 09:59:58PM -0700, Linus Torvalds wrote:
> > PS: NOTE - I'm not going to merge either EVMS or LVM2 right now > as
>things
> > stand. I'm not using any kind of volume management personally, so > > I
>just
> > don't have the background or inclination to walk through the > patches
>and
> > make that kind of decision. My non-scientific opinion is that it > looks
> > like the EVMS code is going to be merged, but ..
> > > Alan, Jens, Christoph, others - this is going to be an area where > >
>I need
> > input from people I know, and preferably also help merging. I've > been
> > happy to see the EVMS patches being discussed on linux-kernel, and > > I
>just > wanted to let people know that this needs outside help.
>I don't think the work to get EVMS in shape can be done in time > (feel
>free to preove me wrong..).
Should EVMS be included, the team will make it our top priority to resolve
the disputed design issues. If the ruling should be that some of our design
decisions must change, so be it, we will comply. Certainly some changes can
not be done by the 20th or 31st, however I feel the team can handle most
changes before 2.6 ships.
>The problem in my eyes is that large
>parts of what evms does should be in the higher layers, i.e. the
>block layer, but they implement their own new layer as the consumer > of
>those. i.e. instead of using the generic block layer structures to
>present a volume/device they use their own,
More accurately, we do use generic block layers structures to present
volumes that are visible to the user/system.
>private structures that
>need hacks to get the access right (pass-through ioctls) and need
>constant resyncing with the native structures in the case where we
>have both (the lowest layer).
The point of contention is that EVMS does not provide generic access (block
layer operations) to the components that make up the volume, but only to the
user/system accessible volumes themselves. EVMS consumes (primarily disk)
devices and produces volumes. The intermediate points are abstracted by the
volume manager.
>IMHO we should try to get a common
>userspace API in first, then implement the missing functionality for
>properly interaction of voulme managers at the block layer. After
>that EVMS would just be a set of coulme mangment drivers + a library
>of common functionality.
>Doing that higher level work will take some time to get right, and the
>current EVMS API seems unsuitable for me, it contains lots of very#
>strange APIs that need rework. Merging EVMS now for 2.6 means that
>we'll have to keep those strange APIs around, and have to maintain
>backwards-compatiblity.
I guess it comes down to the point of whether the block layer should evolve
to also handle volume management generically, or whether volume management
is separate component that utilizes and works with the block layer.
Linus, if you feel that volume management and the block layer can and should
be separate components that work together, then EVMS is ready today, and at
least functionally, could be a pretty good starting point. As a separate
component, only the EVMS tools would have to know or care of the new EVMS
APIs. The volumes EVMS produces, being standard block devices, interface,
interact, and operate as any other block device does today.
Mark
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
-
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/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:43 EST