> > code and your new release _before_ you do that.
>
> The new code *can* automagically read and deal with 0.8 created VGDAs.
> What are you refering too in detail here?
Yes. This is good
The important thing is that the external interface and on disk format dont
break - the code can be
On Wed, 16 May 2001, Heinz J. Mauelshagen wrote:
> Linus, Alan et al.: maybe you could think about it again and
> accept one larger LVM patch. Thanks.
I'm all for it right now. I'm running LVM on practically all my
machines and would really like to have the latest bugfixes
On Fri, May 11, 2001 at 03:32:46PM +0100, Alan Cox wrote:
> > This leads to the dilemma, that trying to avoid further differences between
> > our LVM releases and the stock kernel code would force us into postponing
> > the pending LVM 1.0 release accordingly which OTOH is incovenient for the LVM
On Sun, May 13, 2001 at 08:48:19PM -0300, Rik van Riel wrote:
> On Fri, 11 May 2001, Steven Lembark wrote:
>
> > for my part running the system i'd rather have the "production"
> > LVM and kernel releases in sync and not have to worry about it.
> > if i need a beta/inter-version release then
On Sun, May 13, 2001 at 08:48:19PM -0300, Rik van Riel wrote:
On Fri, 11 May 2001, Steven Lembark wrote:
for my part running the system i'd rather have the production
LVM and kernel releases in sync and not have to worry about it.
if i need a beta/inter-version release then i'll deal
On Fri, May 11, 2001 at 03:32:46PM +0100, Alan Cox wrote:
This leads to the dilemma, that trying to avoid further differences between
our LVM releases and the stock kernel code would force us into postponing
the pending LVM 1.0 release accordingly which OTOH is incovenient for the LVM
On Wed, 16 May 2001, Heinz J. Mauelshagen wrote:
Linus, Alan et al.: maybe you could think about it again and
accept one larger LVM patch. Thanks.
I'm all for it right now. I'm running LVM on practically all my
machines and would really like to have the latest bugfixes in
code and your new release _before_ you do that.
The new code *can* automagically read and deal with 0.8 created VGDAs.
What are you refering too in detail here?
Yes. This is good
The important thing is that the external interface and on disk format dont
break - the code can be
On Sun, May 13, 2001 at 06:36:11PM +0100, David Woodhouse wrote:
> IMHO, no 64-bit architecture code should provide translation functions for
> ioctls from 32-bit binaries.
>
> This is now a sufficiently common requirement that it shouldn't be repeated
> by all architectures that require it -
[EMAIL PROTECTED] said:
> Andrea Arcangeli writes:
> > Related side note: for the x86-64 kernel we won't support the emulation
> > of the lvm ioctl from the 32bit executables to avoid the pointer
> > conversion an mainteinance pain enterely, at least in the early stage
> > the x86-64
[EMAIL PROTECTED] said:
Andrea Arcangeli writes:
Related side note: for the x86-64 kernel we won't support the emulation
of the lvm ioctl from the 32bit executables to avoid the pointer
conversion an mainteinance pain enterely, at least in the early stage
the x86-64 lvmtools will
On Sun, May 13, 2001 at 06:36:11PM +0100, David Woodhouse wrote:
IMHO, no 64-bit architecture code should provide translation functions for
ioctls from 32-bit binaries.
This is now a sufficiently common requirement that it shouldn't be repeated
by all architectures that require it - it
On Fri, May 11, 2001 at 10:19:13PM -0700, David S. Miller wrote:
>
> Andrea Arcangeli writes:
> > you _must_ know very well what the mainteinance of that code means ;).
>
> Which is why I added the facility by which such ioctl conversions can
> be registered at runtime by the subsystem/driver
On Fri, May 11, 2001 at 10:19:13PM -0700, David S. Miller wrote:
Andrea Arcangeli writes:
you _must_ know very well what the mainteinance of that code means ;).
Which is why I added the facility by which such ioctl conversions can
be registered at runtime by the subsystem/driver itself.
Andrea Arcangeli writes:
> you _must_ know very well what the mainteinance of that code means ;).
Which is why I added the facility by which such ioctl conversions can
be registered at runtime by the subsystem/driver itself.
> BTW, it would be nice if somebody would take care of unifying the
On Fri, May 11, 2001 at 01:12:55PM -0700, David S. Miller wrote:
> They can be converted, [..]
of course, and part of that code will be still necessary also with the
>=beta4 lvm interface to still convert the pointers of the userspace
data structures but my point was we probably want to avoid
Andrea Arcangeli writes:
> Related side note: for the x86-64 kernel we won't support the emulation
> of the lvm ioctl from the 32bit executables to avoid the pointer
> conversion an mainteinance pain enterely, at least in the early stage
> the x86-64 lvmtools will have to be compiled elf64.
On Fri, May 11, 2001 at 06:29:27PM -0700, David S. Miller wrote:
> I think that's a bad decision, but it is your's.
Let me put it this way: after I get the first real life request from an
user with an useful case where a 32bit app needs to run the lvm ioctl it
will be truly easy to change my
Andrea Arcangeli writes:
> I just switched to the >=beta4 lvm IOP for all 64bit archs. The previous
> one (the 2.4 mainline one) isn't feasible on the archs with 32bit
> userspace and 64bit kernel (it uses long). The IOP didn't changed btw,
> only the structures changed silenty.
They can be
Alan writes (re LVM):
> Please fix the binary incompatibility in the on disk format between the
> current code and your new release _before_ you do that. The last patches
> I was sent would have screwed every 64bit LVM user.
>
> A new format is fine but import old ones properly. And if you do a
Followup to: <[EMAIL PROTECTED]>
By author:Alan Cox <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> A new format is fine but import old ones properly. And if you do a new format
> stop using kdev_t on disk - it will change size soon
>
Not to mention that it might end up being a
On Fri, May 11, 2001 at 03:32:46PM +0100, Alan Cox wrote:
> Please fix the binary incompatibility in the on disk format between the current
> code and your new release _before_ you do that. The last patches I was sent
> would have screwed every 64bit LVM user.
I just switched to the >=beta4 lvm
On Fri, 11 May 2001, Jeff Garzik wrote:
...
> Subsystems are often maintained outside the Linus tree, with code
> getting pushed (hopefully regularly) to Linus. For such scenarios, it
"maintained" *means* that the fixes/development get fed to Linus.
afaikt, the LVM/ISDN/etc situations were
"Heinz J. Mauelshagen" wrote:
> In order to avoid this difference we provide smaller patches more often now.
> We have started already with a subset of about 50 necessary patches.
>
> Even though we get kind support from Alan Cox to get those QAed and integrated,
> the pure amount of patches
> This leads to the dilemma, that trying to avoid further differences between
> our LVM releases and the stock kernel code would force us into postponing
> the pending LVM 1.0 release accordingly which OTOH is incovenient for the LVM
> user base.
>
> In regard to this situation we'ld like to
As most of you probably know, we've got criticism a couple of weeks ago about
our Linux kernel patch policy causing the LVM vanilla kernel code to differ
from the one we release directly.
In order to avoid this difference we provide smaller patches more often now.
We have started already with a
As most of you probably know, we've got criticism a couple of weeks ago about
our Linux kernel patch policy causing the LVM vanilla kernel code to differ
from the one we release directly.
In order to avoid this difference we provide smaller patches more often now.
We have started already with a
This leads to the dilemma, that trying to avoid further differences between
our LVM releases and the stock kernel code would force us into postponing
the pending LVM 1.0 release accordingly which OTOH is incovenient for the LVM
user base.
In regard to this situation we'ld like to know
Heinz J. Mauelshagen wrote:
In order to avoid this difference we provide smaller patches more often now.
We have started already with a subset of about 50 necessary patches.
Even though we get kind support from Alan Cox to get those QAed and integrated,
the pure amount of patches will take
On Fri, 11 May 2001, Jeff Garzik wrote:
...
Subsystems are often maintained outside the Linus tree, with code
getting pushed (hopefully regularly) to Linus. For such scenarios, it
maintained *means* that the fixes/development get fed to Linus.
afaikt, the LVM/ISDN/etc situations were problems
On Fri, May 11, 2001 at 03:32:46PM +0100, Alan Cox wrote:
Please fix the binary incompatibility in the on disk format between the current
code and your new release _before_ you do that. The last patches I was sent
would have screwed every 64bit LVM user.
I just switched to the =beta4 lvm IOP
Followup to: [EMAIL PROTECTED]
By author:Alan Cox [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
A new format is fine but import old ones properly. And if you do a new format
stop using kdev_t on disk - it will change size soon
Not to mention that it might end up being a pointer, or
Alan writes (re LVM):
Please fix the binary incompatibility in the on disk format between the
current code and your new release _before_ you do that. The last patches
I was sent would have screwed every 64bit LVM user.
A new format is fine but import old ones properly. And if you do a new
Andrea Arcangeli writes:
I just switched to the =beta4 lvm IOP for all 64bit archs. The previous
one (the 2.4 mainline one) isn't feasible on the archs with 32bit
userspace and 64bit kernel (it uses long). The IOP didn't changed btw,
only the structures changed silenty.
They can be
Andrea Arcangeli writes:
you _must_ know very well what the mainteinance of that code means ;).
Which is why I added the facility by which such ioctl conversions can
be registered at runtime by the subsystem/driver itself.
BTW, it would be nice if somebody would take care of unifying the
On Fri, May 11, 2001 at 06:29:27PM -0700, David S. Miller wrote:
I think that's a bad decision, but it is your's.
Let me put it this way: after I get the first real life request from an
user with an useful case where a 32bit app needs to run the lvm ioctl it
will be truly easy to change my mind
Andrea Arcangeli writes:
Related side note: for the x86-64 kernel we won't support the emulation
of the lvm ioctl from the 32bit executables to avoid the pointer
conversion an mainteinance pain enterely, at least in the early stage
the x86-64 lvmtools will have to be compiled elf64.
I
On Fri, May 11, 2001 at 01:12:55PM -0700, David S. Miller wrote:
They can be converted, [..]
of course, and part of that code will be still necessary also with the
=beta4 lvm interface to still convert the pointers of the userspace
data structures but my point was we probably want to avoid that
38 matches
Mail list logo
