From: Christoph Hellwig <hch@infradead.org>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>,
Alan Cox <alan@redhat.com>, Jens Axboe <axboe@suse.de>
Subject: Re: Linux v2.5.42
Date: Sat, 12 Oct 2002 14:32:33 +0100 [thread overview]
Message-ID: <20021012143233.A17090@infradead.org> (raw)
In-Reply-To: <Pine.LNX.4.44.0210112134160.7166-100000@penguin.transmeta.com>; from torvalds@transmeta.com on Fri, Oct 11, 2002 at 09:59:58PM -0700
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
next prev parent reply other threads:[~2002-10-12 13:26 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-12 4:59 Linux v2.5.42 Linus Torvalds
2002-10-12 5:53 ` Adrian Bunk
2002-10-12 7:23 ` Adrian Bunk
2002-10-12 7:52 ` Andres Salomon
2002-10-12 9:23 ` David S. Miller
2002-10-12 9:11 ` Adrian Bunk
2002-10-12 9:24 ` Adrian Bunk
2002-10-12 9:41 ` Sam Ravnborg
2002-10-12 10:21 ` Adrian Bunk
2002-10-12 9:50 ` Matthias Andree
2002-10-12 11:11 ` jw schultz
2002-10-12 11:29 ` Andres Salomon
2002-10-12 11:46 ` Alan Cox
2002-10-12 11:40 ` jw schultz
2002-10-12 17:47 ` Jon Portnoy
2002-10-12 18:10 ` Rik van Riel
2002-10-13 11:58 ` venom
2002-10-13 12:52 ` Michael Clark
2002-10-12 12:37 ` Ed Tomlinson
2002-10-12 13:32 ` Christoph Hellwig [this message]
2002-10-12 19:39 ` Andres Salomon
2002-10-12 13:43 ` Christoph Hellwig
2002-10-13 17:10 ` Dipankar Sarma
2002-10-14 10:01 ` Joe Thornber
2002-10-14 19:21 ` Christoph Hellwig
2002-10-14 19:32 ` Alexander Viro
2002-10-14 22:28 ` Joe Thornber
-- strict thread matches above, loose matches on Subject: below --
2002-10-12 17:14 Mark Peloquin
2002-10-12 19:34 ` Alan Cox
2002-10-12 19:37 ` jbradford
2002-10-13 23:55 ` Rob Landley
2002-10-13 12:41 ` [Evms-devel] " Michael Clark
2002-10-13 13:49 ` Christoph Hellwig
2002-10-13 15:16 ` Michael Clark
2002-10-13 15:35 ` Christoph Hellwig
2002-10-13 16:11 ` Brian Jackson
2002-10-13 16:26 ` Arjan van de Ven
2002-10-13 17:06 ` Brian Jackson
2002-10-13 19:58 ` Mark Hahn
2002-10-13 19:57 ` Rik van Riel
2002-10-13 20:26 ` Sean Neakums
2002-10-24 11:45 ` Alexander Kellett
2002-10-13 19:59 ` Andrew Morton
2002-10-13 20:24 ` Bernd Eckenfels
2002-10-14 15:11 ` Christoph Hellwig
2002-10-14 22:27 ` Bernd Eckenfels
2002-10-13 17:46 ` Robert Love
2002-10-13 18:34 ` Brian Jackson
2002-10-14 14:45 ` Christoph Hellwig
2002-10-13 13:41 ` Christoph Hellwig
2002-10-12 20:20 Dieter Nützel
2002-10-12 22:19 ` Hans Reiser
2002-10-14 17:37 Ben Rafanello
2002-10-15 2:47 Paul McKenney
2002-10-15 17:43 Mark Peloquin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021012143233.A17090@infradead.org \
--to=hch@infradead.org \
--cc=alan@redhat.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox