Re: LVM 1.0 release decision
> > 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-lvm] LVM 1.0 release decision
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 my kernel ;) Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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 [EMAIL PROTECTED] +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-lvm] LVM 1.0 release decision
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 with the > > extra issues. > > Agreed. If the in-kernel LVM cannot be trusted, I really > don't see why Sistina would ever want to associate its name > with something broken? Rik, that's not an issue at all and sorry, it doesn't help either! With the help of community contributors we *do* provide the most recent code with as few bugs as possible at www.sistina.com/lvm as we always did. Everybody could and can get it from there and established LVM users continue to do it this way. OTOH we need a lot of time now to get smaller patches into vanilla. Therefore we kindly asked for community oppinions to help the situation. Unless a bigger LVM patch to vanilla is accepted, we need to spend a lot of work on providing those smaller chunks of patches which distracts us a lot from other work. Don't tell me that this is all our fault; this wouldn't *help* to fasten the process either! A little trust to accept a bigger patch *and* to sort pending issues out with the help of the community afterwards is a valid approach IMO to get faster to the point of an updated vanilla LVM driver than with the tiny patches approach. Linus, Alan et al.: maybe you could think about it again and accept one larger LVM patch. Thanks. > > I think it would be better for everyone (users, Sistina's > corporate image and Linux) to get something stable into the > kernel before sending out the press release ;) > > (after all, a version number change is just a one-liner patch > away ;)) > > regards, > > Rik > -- > Virtual memory is like a game you can't win; > However, without VM there's truly nothing to lose... > > http://www.surriel.com/ http://distro.conectiva.com/ > > Send all your spam to [EMAIL PROTECTED] (spam digging piggy) > > ___ > linux-lvm mailing list > [EMAIL PROTECTED] > http://lists.sistina.com/mailman/listinfo/linux-lvm -- 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 [EMAIL PROTECTED] +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
[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 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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 [EMAIL PROTECTED] 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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 [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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 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 -- <[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
"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 | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: LVM 1.0 release decision
> 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
LVM 1.0 release decision
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 [EMAIL PROTECTED] +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
