> > 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 broken/
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 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
[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
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 i
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 tha
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 mind
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 n
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 poin
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 I
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 probl
"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
> 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
16 matches
Mail list logo
