LVM 1.0 release decision

LVM 1.0 release decision

[Heinz J. Mauelshagen]

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 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 at least a couple of weeks to make it in.

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 about your oppinion on
the following request:
is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code
status are in vanilla (presumed that we provide them with our release as we
always did before)?

We'll gather your answers for some days and will send the conclusion
to the lists.

Thanks for your support!

-- 

Regards,
Heinz    -- The LVM Guy --

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: LVM 1.0 release decision

[Alan Cox]

> 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 about your oppinion on
> the following request:
> is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code

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 format
stop using kdev_t on disk - it will change size soon

Alan

Re: LVM 1.0 release decision

[Andrea Arcangeli]

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 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.

> A new format is fine but import old ones properly. And if you do a new format

It's not a matter of the ondisk format, the on-disk format didn't
changed of course, it's the ioctl format between userspace and kernel 
that changed and the userspace only knows about 1 format. Once IOP
changes (or IOP breaks silenty as in this case) you have to upgrade
userspace with the current design.

Andrea

Re: LVM 1.0 release decision

[David S. Miller]

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 converted, there is in fact initial sparc64 code to
handle the existing LVM ioctls in arch/sparc64/kernel/ioctl32.c

Without argument, the LVM ioctls are done in such a way that
conversion is a bit difficult, but not entirely impossible.

Later,
David S. Miller
davem@redhat.com

Re: LVM 1.0 release decision

[Andrea Arcangeli]

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 complexity
where it's not necessary (feasible was too strong adj sorry).

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.

Andrea

Re: LVM 1.0 release decision

[David S. Miller]

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 think that's a bad decision, but it is your's.

To me, either you support fully the 32-bit execution
environment or you do not.  After all the work that
myself and others have done for other platforms, there
really is no need to cut corners in this area.

My userland on sparc64 is %100 32-bit and everything works
quite beautifully.

Later,
David S. Miller
davem@redhat.com

Re: LVM 1.0 release decision

[Andrea Arcangeli]

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 about that, I just don't expect to
get that request anytime soon because the only thing that runs the lvm
ioctl are the lvmtools, and I assume Andi thought the same when he
originally proposed not to support the lvm ioctl from the 32bit
userland. If you just have in mind something of useful that needs that
please let us know and we will definitely listen to you.

Of course not implementing the 32bit lvm ioctl emulation now, in any
case won't forbid us to implement it in the next 5 minutes, we can do
that anytime if/when we find the first useful case that needs that, it's
just a matter of cut and pasting from the ioctl32.c of sparc64 to the
x86-64 tree and then to spend one day of hacking and testing through
those pointer conversions, being aware that this work will break in the
next two weeks when a new lvm ioctl is added in the next lvm release, or
something like that, you _must_ know very well what the mainteinance of
that code means ;).

BTW, it would be nice if somebody would take care of unifying the
large sharable parts of the emulation code between
x86-64/sparc64/ia64/mips64, this was mentioned by Andi several times but
nothing is been done in that direction yet, they for large part do the
same things and somehow we duplicate efforts across all those ports (if
we exclude the regs maniuplation in the ELF_PLAT_DATA and friends that
can be localized easily). If we do that kind of sharing all the other
ports would probably get the 32bit emulation for the lvm ioctl for free
from the sparc64 effort for example.

> To me, either you support fully the 32-bit execution
> environment or you do not.  After all the work that
> myself and others have done for other platforms, there
> really is no need to cut corners in this area.
>
> My userland on sparc64 is %100 32-bit and everything works
> quite beautifully.

The sparc platform is a completly different matter, you cannot compare
sparc64 to x86-64, on sparc64 the 64bit userspace is a very recent thing
(just to make an example my sparc64 still runs only with the 32bit
userspace and I use the 64bit compiler only for the kernel, I don't know
if you have a total 64bit userspace either).  For sparc64 a 64bit-only
lvmtools would been a very nasty dependency and so for sparc64 it is
almost mandatory to support completly all the ioctls from the 32bit
userland.

On x86-64 the only reason for having a program 32bit is because it's
either binary only, or if you need to reduce the memory footprint and
you don't need more than 4G of address space [btw all the binaries
running in compatibility mode on the x86-64 kernel will get 4G of
address space, 1G more than with a ia32 kernel].  lvmtools are GPL'd and
the memory footprint of the lvmtools is absolutely worthless to
consider. So there's no point to compile the lvmtools 32bit, period.

And I think your "everything works quite beautifully" on sparc64 isn't
really the case if you upgrade to a recent lvm revision unless you fixup
all the 32bit ioctl emulation first, the reason we want "everything
works beautifully and always" is the main reason we try to avoid the lvm
ioctl 32bit emulation ;), at least with the current lvm user<->kernel
design.

Furthmore if somebody post a patch that implements the ioclt wrappers
even if there isn't an useful case that needs them, I will be glad to
checkin that code after adding a fat warning in the source that says it
can break anytime. the lvm ioctl can be run only by the administrator so
it won't be a security breach if they breaks when the drivers/md/lvm*
code gets updated and what I will do in my box will be to compile the
lvmtools with a plain `make` anyways, so my lvmtools will run 64bit
anyways and I will never test that wrappers myself (and after some time
they remains broken I will end putting an #if 0 /* FIXME */ around the
wrappers to avoid somebody getting bitten by that code).

So in short to me it sounds a good decision and also a no brainer one
that we can change anytime if we need to.

Andrea

Re: LVM 1.0 release decision

[David S. Miller]

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
 > large sharable parts of the emulation code between
 > x86-64/sparc64/ia64/mips64, this was mentioned by Andi several times but
 > nothing is been done in that direction yet, they for large part do the
 > same things and somehow we duplicate efforts across all those ports (if
 > we exclude the regs maniuplation in the ELF_PLAT_DATA and friends that
 > can be localized easily). If we do that kind of sharing all the other
 > ports would probably get the 32bit emulation for the lvm ioctl for free
 > from the sparc64 effort for example.

I'm already planning on doing this, but it is a 2.5.x project.
Dave Mosberger agrees with this as has anyone else I've mentioned
the idea to, so consider it basically done in 2.5.x sometime.

Later,
David S. Miller
davem@redhat.com

Re: LVM 1.0 release decision

[Andrea Arcangeli]

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.

Which no one single piece of common code is using yet in 2.4.5pre1 so
right now (2.4.5pre1) you must be doing the mainteinance yourself the
old way.

But I certainly agree that it is promising and that in the future
de-localizing the 32bit wrappers is a good thing so at least people will
see this code when they break it while changing the common code ;).

> I'm already planning on doing this, but it is a 2.5.x project.
> Dave Mosberger agrees with this as has anyone else I've mentioned
> the idea to, so consider it basically done in 2.5.x sometime.

Nice to hear that, when you do that please keep patches@x86-64.org in
CC so we follow it.

After we change the wrapper mechanism by avoiding the mainteinance work by
de-localizing the wrappers and after we share the wrapper logic as well, it
will be a _real_ pleasure to support the lvm ioctl from 32bit userland on
x86-64 too indeed and then it will be a worthwhile effort to support
those ioctl.

Thanks,
Andrea

Re: LVM 1.0 release decision

[David Woodhouse]

davem@redhat.com 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 have to be compiled elf64.

> I think that's a bad decision, but it is your's.

> To me, either you support fully the 32-bit execution environment or
> you do not.  After all the work that myself and others have done for
> other platforms, there really is no need to cut corners in this area.

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 should be somewhere common.
Like linux/abi/ioctl32/



--
dwmw2

Re: LVM 1.0 release decision

[Alan Cox]

> This is now a sufficiently common requirement that it shouldn't be repeated 
> by all architectures that require it - it should be somewhere common.
> Like linux/abi/ioctl32/

Or the 32bit libc shipped with the 64bit box. Lets face it, there is no reason
you can't have a 32bit glibc 2.2 built to use 64bit calling conventions..

Re: LVM 1.0 release decision

[Chris Wedgwood]

On Sun, May 13, 2001 at 07:39:36PM +0100, Alan Cox wrote:

    Or the 32bit libc shipped with the 64bit box. Lets face it, there
    is no reason you can't have a 32bit glibc 2.2 built to use 64bit
    calling conventions..

It doesn't work with binary compatability form other sources (e.g.
trying to run SunOS binaries under ultralinux and such like (I assume
this is possible?)). Then again, should SunOS binaries really be
making such ioctls?



  --cw

Re: LVM 1.0 release decision

[Christoph Hellwig]

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 should be somewhere common.
> Like linux/abi/ioctl32/

Better linux/abi/linux32 and have other 32/64-bit stuff there too.
At least the binfmt_elf32 stuff should be made MI, IMHO.

	Christoph

-- 
Of course it doesn't work. We've performed a software upgrade.

Re: LVM 1.0 release decision

[H. Peter Anvin]

Followup to:  <E14yDyI-0000yE-00@the-village.bc.nu>
By author:    Alan Cox <alan@lxorguk.ukuu.org.uk>
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 go away (to be
replaced with kchrdev_t, kblkdev_t or something like that.)

*** kdev_t does not belong in user space or on disk; it is a kernel
    transient object. ***

Personally I can't believe this code went into the mainstream kernel
*at all* with this wart in it.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: LVM 1.0 release decision

[Andreas Dilger]

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 format
> stop using kdev_t on disk - it will change size soon

Actually, there is no need to store kdev_t on disk at all, nor is there a
need to store device name.  By the time you have located the device, you
don't need that information any more.  I think that stuff is just a hold
over from when in-core and on-disk data was the same, and should be removed.

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: LVM 1.0 release decision

[Heinz J. Mauelshagen]

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
> > user base.
> > 
> > In regard to this situation we'ld like to know about your oppinion on
> > the following request:
> > is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code
> 
> Please fix the binary incompatibility in the on disk format between the current
> 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?


> The last patches I was sent
> would have screwed every 64bit LVM user.

Patrick is investigating here.

> 
> 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

We don't need it any longer in the PV struct.

In the LV struct we can change it easily, because we just need the minor
number which will nicely fit into the 32 bit we have.

> 
> Alan

-- 

Regards,
Heinz    -- The LVM Guy --

*** Software bugs are stupid.
    Nevertheless it needs not so stupid people to solve them ***

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Heinz Mauelshagen                                 Sistina Software Inc.
Senior Consultant/Developer                       Am Sonnenhang 11
                                                  56242 Marienrachdorf
                                                  Germany
Mauelshagen@Sistina.com                           +49 2626 141200
                                                       FAX 924446
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Re: LVM 1.0 release decision

[Alan Cox]

> > 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/mended repeatedly the ABI is rather harder
to cure

> In the LV struct we can change it easily, because we just need the minor
> number which will nicely fit into the 32 bit we have.

Ok.  

Re: LVM 1.0 release decision

[Jeff Garzik]

"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 at least a couple of weeks to make it in.

Are you sending them all in one batch (50 e-mails to Linus at once), or
trickling them to Linus a few at a time?  It might be faster to send him
a batch (though not necessarily 50), noting with each e-mail, after each
patch's description, that the particular patch depends patches C, F, and
H that have come before it.  That way Linus can apply 8 out of 10
patches, and then you synchronize with him and start the cycle over
again.


> In regard to this situation we'ld like to know about your oppinion on
> the following request:
> is it acceptable to release 1.0 soon *before* all patches to reach the 1.0 code
> status are in vanilla (presumed that we provide them with our release as we
> always did before)?

Subsystems are often maintained outside the Linus tree, with code
getting pushed (hopefully regularly) to Linus.  For such scenarios, it
should be no problem to release software before all of it passes Linus. 
You are the one who has to deal with user support after all :)   Just
make sure that all fixes and changes currently in the kernel are also in
your software release...

	Jeff


-- 
Jeff Garzik      | Game called on account of naked chick
Building 1024    |
MandrakeSoft     |

Re: LVM 1.0 release decision

[Mark Hahn]

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 because the developers
merely hacked on code, and failed to do the maintenance (feed Linus) part.