Messages in this thread | | | Date | Sat, 12 Oct 2002 15:39:36 -0400 | From | Andres Salomon <> | Subject | Re: Linux v2.5.42 |
| |
2.5 LVM2 patches in non-BK form: http://people.sistina.com/~thornber/dm_2002-10-09.tar.bz2
Joe, it would be nice if you linked to that from p.s.c/~thornber/; or, if you're going to be releasing a bunch of patches, make a dm directory w/ directoryindexing enabled.
On Sat, Oct 12, 2002 at 02:32:33PM +0100, 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..). 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, 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). 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've not seen LVM2 code for 2.5 yet, but the 2.4 code looks very > promising, although it might need some work in different areas. > I'll take a look as soon as Sistina publishes patches for 2.5 instead > of just a BK repository. LVM1 is totally unusable in 2.5, I think > we should better remove the dead code now than later. > > Christoph > > - > 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/
-- It's not denial. I'm just selective about the reality I accept. -- Bill Watterson - 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/
| |