[mec]
> > Peter, your patch fails if CONFIG_BLK_DEV_MD=m and CONFIG_BLK_DEV_LVM=y.
Ewww, you're right. As I believe I already mentioned, this is why I
was originally opposed to mixing lvm and md into one directory. Not
that this was a valid objection, of course.
The easy fix would be to
On Tue, 26 Sep 2000, Michael Elizabeth Chastain wrote:
> Peter, your patch fails if CONFIG_BLK_DEV_MD=m and CONFIG_BLK_DEV_LVM=y.
>
> The simple correct way is to use some ugly temporary variables:
> MD and MMD.
Temporary variables shouldn't be needed... We need to put
drivers/md in both
Peter, your patch fails if CONFIG_BLK_DEV_MD=m and CONFIG_BLK_DEV_LVM=y.
The simple correct way is to use some ugly temporary variables:
MD and MMD.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
[Jeff Garzik <[EMAIL PROTECTED]>]
> We don't need a config option just to jump into another directory.
> Probably just a makefile or config bug..
Yeah, this is not well-tested but at least *looks* obviously correct.
(BTW the ugliness in drivers/makefile is sort of why I was originally
opposed
[Jeff Garzik [EMAIL PROTECTED]]
We don't need a config option just to jump into another directory.
Probably just a makefile or config bug..
Yeah, this is not well-tested but at least *looks* obviously correct.
(BTW the ugliness in drivers/makefile is sort of why I was originally
opposed to
Peter, your patch fails if CONFIG_BLK_DEV_MD=m and CONFIG_BLK_DEV_LVM=y.
The simple correct way is to use some ugly temporary variables:
MD and MMD.
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the
On Tue, 26 Sep 2000, Michael Elizabeth Chastain wrote:
Peter, your patch fails if CONFIG_BLK_DEV_MD=m and CONFIG_BLK_DEV_LVM=y.
The simple correct way is to use some ugly temporary variables:
MD and MMD.
Temporary variables shouldn't be needed... We need to put
drivers/md in both SUB_DIRS
[mec]
Peter, your patch fails if CONFIG_BLK_DEV_MD=m and CONFIG_BLK_DEV_LVM=y.
Ewww, you're right. As I believe I already mentioned, this is why I
was originally opposed to mixing lvm and md into one directory. Not
that this was a valid objection, of course.
The easy fix would be to
On Mon, 25 Sep 2000, Jan Niehusmann wrote:
> > But I don't think there is anything wrong with grouping RAID and LVM under
> > the title "md", and just leaving it as such.
> It seems that the current setup makes it impossible to compile lvm without
> compiling md.c. But md.c is not needed for
On Mon, Sep 25, 2000 at 08:04:36PM +0200, Jan Niehusmann wrote:
> compiling md.c. But md.c is not needed for lvm, is it?
It is not needed, correct.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ
> But I don't think there is anything wrong with grouping RAID and LVM under
> the title "md", and just leaving it as such.
It seems that the current setup makes it impossible to compile lvm without
compiling md.c. But md.c is not needed for lvm, is it?
I think we need two different config
But I don't think there is anything wrong with grouping RAID and LVM under
the title "md", and just leaving it as such.
It seems that the current setup makes it impossible to compile lvm without
compiling md.c. But md.c is not needed for lvm, is it?
I think we need two different config
On Mon, Sep 25, 2000 at 08:04:36PM +0200, Jan Niehusmann wrote:
compiling md.c. But md.c is not needed for lvm, is it?
It is not needed, correct.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ
On Sat, Sep 23, 2000 at 01:34:33PM -0500, Peter Samuelson wrote:
> common association. It's a documentation issue as much as anything,
Agreed.
> and you've basically taken care of that in -pre6.
Looks fine to me too.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe
[Peter Samuelson]
> > "md", on the other hand, is well-established as referring to Linux
> > RAID, but if you add lvm the label is too narrow.
[Linus]
> Yes, we have all thes _historical_ reasons why people think "md"
> refers to the particular RAID code in question. But so what? LVM is
>
On Fri, 22 Sep 2000, Peter Samuelson wrote:
>
> But most if not all block drivers, and some char drivers for that
> matter, could be considered part of "storage management". So the label
> is too broad. "md", on the other hand, is well-established as
> referring to Linux RAID, but if you add
[Peter Samuelson]
"md", on the other hand, is well-established as referring to Linux
RAID, but if you add lvm the label is too narrow.
[Linus]
Yes, we have all thes _historical_ reasons why people think "md"
refers to the particular RAID code in question. But so what? LVM is
also very
Peter Samuelson wrote:
> But most if not all block drivers, and some char drivers for that
> matter, could be considered part of "storage management". So the label
> is too broad. "md", on the other hand, is well-established as
> referring to Linux RAID, but if you add lvm the label is too
[aa]
> Ok, I see your point of grouping them together.
>
> So I think drivers/sm (Storage Management) would be cleaner. LVM and
> MD are two implementations of Storage Management.
But most if not all block drivers, and some char drivers for that
matter, could be considered part of "storage
On Fri, Sep 22, 2000 at 01:48:23PM -0700, Linus Torvalds wrote:
> (and I think LVM can do striping too). Yes, they have different
Yes LVM does striping too (it overlaps with raid0 functionality provided
by MD).
> It makes sense to group them together. Neither is a true hardware
> driver, and
In article <[EMAIL PROTECTED]>,
Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>On Thu, Sep 21, 2000 at 04:11:46PM +0200, Jan Niehusmann wrote:
>> Yes, lvm.c and lvm-snap.c are missing from drivers/md/.
>
>LVM and MD have nothing common.
I disagree.
Yes, they have no _code_ in common. They have
In article [EMAIL PROTECTED],
Andrea Arcangeli [EMAIL PROTECTED] wrote:
On Thu, Sep 21, 2000 at 04:11:46PM +0200, Jan Niehusmann wrote:
Yes, lvm.c and lvm-snap.c are missing from drivers/md/.
LVM and MD have nothing common.
I disagree.
Yes, they have no _code_ in common. They have a
[aa]
Ok, I see your point of grouping them together.
So I think drivers/sm (Storage Management) would be cleaner. LVM and
MD are two implementations of Storage Management.
But most if not all block drivers, and some char drivers for that
matter, could be considered part of "storage
Peter Samuelson wrote:
But most if not all block drivers, and some char drivers for that
matter, could be considered part of "storage management". So the label
is too broad. "md", on the other hand, is well-established as
referring to Linux RAID, but if you add lvm the label is too narrow.
On Thu, Sep 21, 2000 at 06:38:39PM -0500, Peter Samuelson wrote:
> Right. Functionally they overlap (lvm can do the equivalent of md
> linear) but structurally, the md drivers all operate under the md
lvm can do linear and raid0 (striping in two or more disks), and it supports
live snapshotting
[Andrea]
> LVM and MD have nothing common. They're two completly orthogonal
> piece of code
Right. Functionally they overlap (lvm can do the equivalent of md
linear) but structurally, the md drivers all operate under the md
framework and user-toolset while lvm has its own framework and
On Thu, Sep 21, 2000 at 05:47:36PM +0200, Andrea Arcangeli wrote:
> On Thu, Sep 21, 2000 at 04:11:46PM +0200, Jan Niehusmann wrote:
> > Yes, lvm.c and lvm-snap.c are missing from drivers/md/.
>
> LVM and MD have nothing common.
Yes, I know. I'm not arguing about the right location for lvm. But
On Thu, Sep 21, 2000 at 04:11:46PM +0200, Jan Niehusmann wrote:
> Yes, lvm.c and lvm-snap.c are missing from drivers/md/.
LVM and MD have nothing common. They're two completly orthogonal piece of code
(you can put LVM on top of MD but that's just because of the nice reentrance of
the blkdev API
On Wed, Sep 20, 2000 at 08:54:55PM -0400, Mohammad A. Haque wrote:
> I think lvm and lvm-snap didn't get moved into the md dir. Or maybe the
> Makefile in md needs to be fixed.
Yes, lvm.c and lvm-snap.c are missing from drivers/md/.
Additionally, drivers/Makefile needs to be modified: If you
On Wed, Sep 20, 2000 at 08:54:55PM -0400, Mohammad A. Haque wrote:
I think lvm and lvm-snap didn't get moved into the md dir. Or maybe the
Makefile in md needs to be fixed.
Yes, lvm.c and lvm-snap.c are missing from drivers/md/.
Additionally, drivers/Makefile needs to be modified: If you use
On Thu, Sep 21, 2000 at 04:11:46PM +0200, Jan Niehusmann wrote:
Yes, lvm.c and lvm-snap.c are missing from drivers/md/.
LVM and MD have nothing common. They're two completly orthogonal piece of code
(you can put LVM on top of MD but that's just because of the nice reentrance of
the blkdev API
On Thu, Sep 21, 2000 at 05:47:36PM +0200, Andrea Arcangeli wrote:
On Thu, Sep 21, 2000 at 04:11:46PM +0200, Jan Niehusmann wrote:
Yes, lvm.c and lvm-snap.c are missing from drivers/md/.
LVM and MD have nothing common.
Yes, I know. I'm not arguing about the right location for lvm. But lvm
[Andrea]
LVM and MD have nothing common. They're two completly orthogonal
piece of code
Right. Functionally they overlap (lvm can do the equivalent of md
linear) but structurally, the md drivers all operate under the md
framework and user-toolset while lvm has its own framework and toolset.
On Thu, Sep 21, 2000 at 06:38:39PM -0500, Peter Samuelson wrote:
Right. Functionally they overlap (lvm can do the equivalent of md
linear) but structurally, the md drivers all operate under the md
lvm can do linear and raid0 (striping in two or more disks), and it supports
live snapshotting
I think lvm and lvm-snap didn't get moved into the md dir. Or maybe the
Makefile in md needs to be fixed.
--
=
Mohammad A. Haque http://www.haque.net/
I think lvm and lvm-snap didn't get moved into the md dir. Or maybe the
Makefile in md needs to be fixed.
--
=
Mohammad A. Haque http://www.haque.net/
36 matches
Mail list logo
