[lkml]   [2002]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Linux v2.5.42
    2.5 LVM2 patches in non-BK form:

    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
    > More majordomo info at
    > Please read the FAQ at

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:30    [W:0.025 / U:8.316 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site