Re: [RFC, Announce] Unified x86 architecture, arch/x86
* Pavel Machek ([EMAIL PROTECTED]) wrote: > I believe there's still a lot that can be merged, and I'm responsible > for some of it. Parts of suspend code should be shared, yet they are > in differently named files in differently named directories. > > Ok, I guess I should fix it, arch/x86 or not. Funny, I was just looking at that code specifically. Yes, it would be useful to share. It will need some wrappers for the asm which are now paravirt on i386 and still raw on x86_64 (have those handy if you need them). thanks, -chris - 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: [RFC, Announce] Unified x86 architecture, arch/x86
Hi! > > This patch was the beginning of the merger, not the end result. It strived > > for binary identical images. It was to put everything together as a > > _starting_point_! The next thing to do after this is to start the > > merging. > > Well we've been merging what makes sense since several years. So it's not > really starting anything that hasn't already occurred. I believe there's still a lot that can be merged, and I'm responsible for some of it. Parts of suspend code should be shared, yet they are in differently named files in differently named directories. Ok, I guess I should fix it, arch/x86 or not. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - 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: Fwd: [RFC, Announce] Unified x86 architecture, arch/x86
On Jul 21 2007 23:17, . . wrote: > -- Forwarded message -- > From: . . <[EMAIL PROTECTED]> > Date: Jul 21, 2007 11:08 PM > Subject: [RFC, Announce] Unified x86 architecture, arch/x86 > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL > PROTECTED], > [EMAIL PROTECTED], [EMAIL PROTECTED] > > Hi all! > > [please CC me] > > I think, for this time is te good, for starting the 2.7-tree. I know, > thet is the old question, but has everything in his favour: > * arch unifie (i386 + x86_84 -> x86) > * new virtualisation technik (xen, kvm, lguest) > * new FS (ext4, reiser4) > * new cpu-scheduler (CFS) > * soo many patch in -mm tree > * subsystem modifications So what? Interesting stuff got merged in 2.6.16, .18, .20, .22, and perhaps many others inbetween. Nothing stands out. And since you seem to know better, what would trigger a 2.8 release, and _when_? Jan -- - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Sun, Jul 22, 2007 at 09:50:46AM +0200, Thomas Gleixner wrote: > On Sat, 2007-07-21 at 16:51 -0700, Chris Wright wrote: > > * Matt Mackall ([EMAIL PROTECTED]) wrote: > > > Can we see some stats on: > > > > > > How many files were auto-merged? > > > How many files got 32.c and 64.c extensions? > > > How many existed only in one arch? > > > > It's mostly about file movement first. > > > > 918 files changed, 4745 insertions(+), 2836 deletions(-) > > Hmm, did you forget to make distclean ? > > Numbers from the script: > > include/asm-i386 240 files > include/asm-x86_64 169 files > -- > 409 files > > include/asm-x86 389 files > > arch/i386335 files > arch/x86_64 141 files > -- > 476 files > > arch/x86 484 files > > The increase here is due to migration helper files which only include > the (_32.x or the _64.x) variant. > > Makefile helpers 9 files > Kconfig helpers1 file > Source helpers 4 files > -- > 14 files > > Summary: > vanilla22657 files > vanilla->x86 22649 files > > -- > > include/x86 has 125 _32 and 125 _64 files > arch/x86 has 55 _32 and 55 _64 files > > 25 files were auto-merged > > Looking at include/asm-x86/*_[32/64].h there are offhand ~ 50 of the 125 > which differ only minimal (white space damage, comment changes, ...), > where the unification is a no brainer. That looks more promising than I would have expected. For what it's worth, I was originally fairly disgusted by the _32/64.c thing, but the idea grows on me. -- Mathematics is the supreme nostalgia of our time. - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Sat, 2007-07-21 at 16:51 -0700, Chris Wright wrote: > * Matt Mackall ([EMAIL PROTECTED]) wrote: > > Can we see some stats on: > > > > How many files were auto-merged? > > How many files got 32.c and 64.c extensions? > > How many existed only in one arch? > > It's mostly about file movement first. > > 918 files changed, 4745 insertions(+), 2836 deletions(-) Hmm, did you forget to make distclean ? Numbers from the script: include/asm-i386 240 files include/asm-x86_64 169 files -- 409 files include/asm-x86 389 files arch/i386335 files arch/x86_64 141 files -- 476 files arch/x86 484 files The increase here is due to migration helper files which only include the (_32.x or the _64.x) variant. Makefile helpers 9 files Kconfig helpers1 file Source helpers 4 files -- 14 files Summary: vanilla22657 files vanilla->x86 22649 files -- include/x86 has 125 _32 and 125 _64 files arch/x86 has 55 _32 and 55 _64 files 25 files were auto-merged Looking at include/asm-x86/*_[32/64].h there are offhand ~ 50 of the 125 which differ only minimal (white space damage, comment changes, ...), where the unification is a no brainer. tglx - 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: [RFC, Announce] Unified x86 architecture, arch/x86
* Matt Mackall ([EMAIL PROTECTED]) wrote: > Can we see some stats on: > > How many files were auto-merged? > How many files got 32.c and 64.c extensions? > How many existed only in one arch? It's mostly about file movement first. Kbuild |8 +- Makefile | 23 +- arch/i386/Kconfig | 1275 +- arch/i386/Makefile | 208 +-- arch/i386/kernel/early_printk.c|2 - arch/i386/kernel/tsc_sync.c|1 - arch/x86/Kconfig | 1919 arch/{i386 => x86}/Kconfig.cpu |0 arch/{i386 => x86}/Kconfig.debug | 50 +- arch/x86/Kconfig_32| 1283 + arch/{i386/Kconfig.debug => x86/Kconfig_32.debug} |0 arch/x86/Kconfig_64| 792 .../{x86_64/Kconfig.debug => x86/Kconfig_64.debug} |0 arch/x86/Makefile |5 + arch/{i386 => x86}/Makefile.cpu|0 arch/x86/Makefile_32 | 163 ++ arch/x86/Makefile_64 | 128 ++ arch/{i386 => x86}/boot/.gitignore |0 arch/{i386 => x86}/boot/Makefile |6 +- arch/{i386 => x86}/boot/a20.c |0 arch/{i386 => x86}/boot/apm.c |0 arch/{i386 => x86}/boot/bitops.h |0 arch/{i386 => x86}/boot/boot.h |0 arch/{i386 => x86}/boot/cmdline.c |0 arch/{i386 => x86}/boot/code16gcc.h|0 arch/{i386 => x86}/boot/compressed/.gitignore |0 arch/x86/boot/compressed/Makefile |5 + .../Makefile => x86/boot/compressed/Makefile_32} |8 +- .../Makefile => x86/boot/compressed/Makefile_64} |8 +- .../head.S => x86/boot/compressed/head_32.S} |0 .../head.S => x86/boot/compressed/head_64.S} |0 .../misc.c => x86/boot/compressed/misc_32.c} |0 .../misc.c => x86/boot/compressed/misc_64.c} |0 arch/{i386 => x86}/boot/compressed/relocs.c|0 .../boot/compressed/vmlinux_32.lds}|0 .../boot/compressed/vmlinux_32.scr}|0 .../boot/compressed/vmlinux_64.lds}|0 .../boot/compressed/vmlinux_64.scr}|0 arch/{i386 => x86}/boot/copy.S |0 arch/{i386 => x86}/boot/cpu.c |0 arch/{i386 => x86}/boot/cpucheck.c |0 arch/{i386 => x86}/boot/edd.c |0 arch/{i386 => x86}/boot/header.S |0 arch/{i386 => x86}/boot/install.sh |0 arch/{i386 => x86}/boot/main.c |0 arch/{i386 => x86}/boot/mca.c |0 arch/{i386 => x86}/boot/memory.c |0 arch/{i386 => x86}/boot/mtools.conf.in |0 arch/{i386 => x86}/boot/pm.c |0 arch/{i386 => x86}/boot/pmjump.S |0 arch/{i386 => x86}/boot/printf.c |0 arch/x86/boot/setup.S |7 + arch/{i386 => x86}/boot/setup.ld |0 arch/{i386 => x86}/boot/string.c |0 arch/{i386 => x86}/boot/tools/.gitignore |0 arch/{i386 => x86}/boot/tools/build.c |0 arch/{i386 => x86}/boot/tty.c |0 arch/{i386 => x86}/boot/version.c |0 arch/{i386 => x86}/boot/vesa.h |0 arch/{i386 => x86}/boot/video-bios.c |0 arch/{i386 => x86}/boot/video-vesa.c |0 arch/{i386 => x86}/boot/video-vga.c|0 arch/{i386 => x86}/boot/video.c|0 arch/{i386 => x86}/boot/video.h|0 arch/{i386 => x86}/boot/voyager.c |0 arch/x86/crypto/Makefile |5 + .../crypto/Makefile => x86/crypto/Makefile_32} |4 +- .../crypto/Makefile => x86/crypto/Makefile_64} |4 +- arch/{i386 => x86}/crypto/aes-i586-asm.S |0 arch/{x86_64 => x86}/crypto/aes-x86_64-asm.S |0 arch/{i386/crypto/aes.c => x86/crypto/aes_32.c}|0 arch/{x86_64/crypto/aes.c => x86/crypto/aes_64.c} |0 arch/{i386 => x86}/crypto/twofish-i586-asm.S |0 arch/{x86_64 => x86}/crypto/twofish-x86_64-asm.S |0 .../crypto/twofish.c => x86/crypto/twofish_32.c} |0 .../crypto/twofish.c => x86/crypto/twofish_64.c} |0 arch/{i386/defconfig => x86/defconfig_32} |0 arch/{x86_64/defconfig => x86/defconfig_64}|0 a
Re: [RFC, Announce] Unified x86 architecture, arch/x86
On Sat, Jul 21, 2007 at 12:32:59AM +0200, Thomas Gleixner wrote: > How is the new arch/x86 and include/asm-x86 namespace layed out? Our > foremost concern was to enable a 100% smooth transition to the new, > shared architecture, while still enabling much more fine-grained future > unification of the source code. To do this we consciously aimed for the > strictest possible unification strategy: we only 'unified' those source > files that are already bit for bit equal between the two architectures > today. For all other files we used the following rule: if a file came > from arch/i386/foo/bar.c, it gets moved to arch/x86/foo/bar_32.c, if it > came from arch/x86_64/foo/bar.c it gets moved to arch/x86/foo/bar_64.c. > We also generated arch/x86/foo/bar.c that simply #include's those two > files (depending on whether we do a 32-bit or a 64-bit built). If a file > only existed in only one of the architectures, it's moved to > arch/x86/foo/bar.c straight away. (take a look at our git repository to > see how this works out in practice.) Can we see some stats on: How many files were auto-merged? How many files got 32.c and 64.c extensions? How many existed only in one arch? -- Mathematics is the supreme nostalgia of our time. - 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: [RFC, Announce] Unified x86 architecture, arch/x86
* From: Alan Cox * Date: Sat, 21 Jul 2007 00:55:12 +0100 * Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 > > On Fri, 20 Jul 2007 18:38:39 -0400 > Jeff Garzik <[EMAIL PROTECTED]> wrote: > >> I agree with Andi... it's quite nice to be able to leave some arch/i386 >> stuff, and not carry it over to arch/x86-64. > > Its easy enough to push that stuff into arch/x86/legacy and have one > subdirectory of stuff to pull in for ancient systems. Or if i386 and virualization guys don't want to quietly break/mess with stuff pulled by x86-64, move it to x86-64 instead. Elegant, easy, honors Andi. - 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/
Fwd: [RFC, Announce] Unified x86 architecture, arch/x86
-- Forwarded message -- From: . . <[EMAIL PROTECTED]> Date: Jul 21, 2007 11:08 PM Subject: [RFC, Announce] Unified x86 architecture, arch/x86 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Hi all! [please CC me] I think, for this time is te good, for starting the 2.7-tree. I know, thet is the old question, but has everything in his favour: * arch unifie (i386 + x86_84 -> x86) * new virtualisation technik (xen, kvm, lguest) * new FS (ext4, reiser4) * new cpu-scheduler (CFS) * soo many patch in -mm tree * subsystem modifications thanks Oliver - 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: [RFC, Announce] Unified x86 architecture, arch/x86
> Besides radical file movements like this are bad anyways. They cause > a big break in patchkits and forward/backwards porting that doesn't > really help anybody. Sorry Andi but I strongly disagree with your disapproval of this. for existing out of tree patches it's not a big break, it's one sed script away (until consolidation happens). For distro backports... well that's a distro problem; the distros get paid to do that work by their customers. We really can't hold back mainline progress for that Having one tree is a lot of progress; it means we (Intel and the rest of the kernel community) only have to add features, bugfixes and quirks to one place. It means testing is shared. It means feature sets are shared. The only argument against is "but there are quirks in the old one that I don't want to see".. well Thomas solves that by having a clean way to do per 32/64 files for the few cases where it's needed. -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On 7/21/07, Andi Kleen <[EMAIL PROTECTED]> wrote: [of which several just #include Why will it fork? I don't think it will ever happen that the trees will have large pieces that _has_ to be different one from the other. So if it's forking to achieve some benefits, why can't i386 get the benefits too? I think this is the whole point here. Surely as it is today (and just because it wasn't merged earlier and the past!), the x86_64 tree has a bunch of things that are quite better structured than the i386 (and maybe vice-versa, but I must admit that unlike Steven Roasted, I like the x86_64 a lot more). But in the long term, it tends to just get the best of each picked up. And oh yeah, i386 is older, has a lot more corner cases, but even if it does count against the merge, we have a net win at the end. -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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: [RFC, Announce] Unified x86 architecture, arch/x86
* Brian Gerst <[EMAIL PROTECTED]> wrote: > > And there is more of that, when you take the time and look closely > > at the _32.[ch] _64.[ch] files which are created by the merge. > > Looking at the include files, many more are near-identical in trivial > ways, such as whitespace, comments, local variable names, or guard > #ifdefs. yeah. And by moving them next to each other, people actually have the real incentive to look and ponder: "these two files do similar things but they look so different. Does it _have_ to be so?". Often the answer is: no, it could really be shared. And even when things will continue to be different, it's nice to have them side by side for documentation purposes as well. "we do this differently on 64-bit, because ...". Key to starting all these cleanups is to create plain and simple physical proximity - and our transition arch/x86 and include/asm-x86 achieves that - nothing more, nothing less. Ingo - 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: [RFC, Announce] Unified x86 architecture, arch/x86
Thomas Gleixner wrote: > On Sat, 2007-07-21 at 07:37 +0200, Andi Kleen wrote: >> On Saturday 21 July 2007 00:32, Thomas Gleixner wrote: >>> As an initial matter, we made it painstakingly sure that the resulting >>> .o files in a 32-bit build are bit for bit equal. >> You got not a single line less code duplication then, so i don't really >> see the point of this. > > Really ? > > The script detected 15 identical files with a simple cmp. > > It also unified another 10 by simply looking at the only line in there > "include " > > And there is more of that, when you take the time and look closely at > the _32.[ch] _64.[ch] files which are created by the merge. Looking at the include files, many more are near-identical in trivial ways, such as whitespace, comments, local variable names, or guard #ifdefs. -- Brian Gerst - 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: [RFC, Announce] Unified x86 architecture, arch/x86
Thanks for doing this, it's definitely the way to go. After a quick look over it, I noted a small mistake: After the arch/x86_64/kernel/Makefile -> arch/x86/kernel/Makefile_64 transition, the three foo-$(subst m,y,$(CONFIG_BAR)) got replaced with foo-$(CONFIG_BAR). Although the subst's look fishy, such changes shouldn't be part of the architecture merge. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Sat, 2007-07-21 at 00:32 +0200, Thomas Gleixner wrote: > We are pleased to announce a project we've been working on for some > time: the unified x86 architecture tree, or "arch/x86" - and we'd like > to solicit feedback about it. Oooh, shiny. We've been talking about how useful this would be for years. Experience with the unification of PowerPC shows that it's definitely the right thing to do -- it reduces the number of gratuitous differences between 32-bit and 64-bit code, and makes it far more easier to ensure that bug-fixes and new features get added to both at the same time. > When should this go upstream? > - > > We actually think that the sooner we get over with this, the better. I'm inclined to agree. -- 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Sat, 2007-07-21 at 10:15 +0200, Thomas Gleixner wrote: > On Sat, 2007-07-21 at 07:37 +0200, Andi Kleen wrote: > > On Saturday 21 July 2007 00:32, Thomas Gleixner wrote: > > > We are pleased to announce a project we've been working on for some > > > time: the unified x86 architecture tree, or "arch/x86" - and we'd like > > > to solicit feedback about it. > > > > Well you know my position on this. I think it's a bad idea because > > it means we can never get rid of any old junk. IMNSHO arch/x86_64 > > is significantly cleaner and simpler in many ways than arch/i386 and I would > > like to preserve that. Also in general arch/x86_64 is much easier to hack > > than arch/i386 because it's easier to regression test and in general > > has to care about much less junk. And I don't > > know of any way to ever fix that for i386 besides splitting the old > > stuff off completely. > > I disagree of course. > > I worked on both trees quite intensive over the last years and I broke > x86_64 more than once when hacking on i386 and vice versa. Me too. At the very least I'd like to see asm-x86/ for headers used by both. That said, the merge is exactly as I'd have done it. So if this were a democracy, I'd vote in favour. Cheers, Rusty. - 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: [RFC, Announce] Unified x86 architecture, arch/x86
* Andi Kleen <[EMAIL PROTECTED]> wrote: > > It happens so often that someone accidentally breaks one > > architecture because he didn't notice the code also gets used on the > > other architecture. > > That's not changing at all. Especially with even more sharing, (than I > think would be prudent) like Thomas treated, you'll likely have to > test compile both for most changes. yes, very much so, and that's exactly one of our points. Ingo - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Saturday 21 July 2007 10:15:50 Thomas Gleixner wrote: > > The script detected 15 identical files with a simple cmp. You mean arch/i386/boot/.gitignore arch/i386/boot/tools/.gitignore arch/i386/oprofile/Kconfig include/asm-i386/poll.h include/asm-i386/emergency-restart.h include/asm-i386/spinlock_types.h include/asm-i386/vga.h include/asm-i386/msidef.h include/asm-i386/hypertransport.h include/asm-i386/ioctl.h include/asm-i386/fcntl.h ? [of which several just #include http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, Announce] Unified x86 architecture, arch/x86
On Sat, 2007-07-21 at 07:37 +0200, Andi Kleen wrote: > On Saturday 21 July 2007 00:32, Thomas Gleixner wrote: > > We are pleased to announce a project we've been working on for some > > time: the unified x86 architecture tree, or "arch/x86" - and we'd like > > to solicit feedback about it. > > Well you know my position on this. I think it's a bad idea because > it means we can never get rid of any old junk. IMNSHO arch/x86_64 > is significantly cleaner and simpler in many ways than arch/i386 and I would > like to preserve that. Also in general arch/x86_64 is much easier to hack > than arch/i386 because it's easier to regression test and in general > has to care about much less junk. And I don't > know of any way to ever fix that for i386 besides splitting the old > stuff off completely. I disagree of course. I worked on both trees quite intensive over the last years and I broke x86_64 more than once when hacking on i386 and vice versa. Your "junk" argument is nothing else than a strawman which you beat on every time when this discussion comes up. > Besides radical file movements like this are bad anyways. They cause > a big break in patchkits and forward/backwards porting that doesn't > really help anybody. Interestingly enough the folks with the big patch kits (Virtualization) would be quite happy about that move. > > This causes double maintenance > > even for functionality that is conceptually the same for the 32-bit and > > the 64-bit tree. (such as support for standard PC platform architecture > > devices) > > It's not really the same platform: one is PC hardware going back forever > with zillions of bugs, the other is modern PC platforms which much less > bugs and quirks It _IS_ the same platform. x86_64 is PC hardware with zillions of bugs as well. And it is not modern at all. It is nothing else than a 64 bit version of the legacy x86. > To see it otherwise it's more a junkification of arch/x86_64 than > a cleanup of arch/i386 -- in fact you didn't really clean up arch/i386 > at all. We went for a 1 : 1 replacement without merging anything which is not obvious in the first place (identical files and files, which are just including some other file). That way we were able to do a binary compatible migration. The clean up is the next step and there are enough folks out there willing to help on this. > > As an initial matter, we made it painstakingly sure that the resulting > > .o files in a 32-bit build are bit for bit equal. > > You got not a single line less code duplication then, so i don't really > see the point of this. Really ? The script detected 15 identical files with a simple cmp. It also unified another 10 by simply looking at the only line in there "include " And there is more of that, when you take the time and look closely at the _32.[ch] _64.[ch] files which are created by the merge. tglx - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Sat, 2007-07-21 at 09:42 +0200, Andi Kleen wrote: > > > > It happens so often that someone accidentally breaks one architecture > > because he didn't notice the code also gets used on the other > > architecture. > > That's not changing at all. Especially with even more sharing, (than I think > would be prudent) like Thomas treated, you'll likely have to test compile both > for most changes. And a shared code base makes it entirely clear, that you must recheck bot ARCHs when you touch code in there. Right now it is not clear at all. tglx - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Sat, Jul 21, 2007 at 09:42:48AM +0200, Andi Kleen wrote: > On Saturday 21 July 2007 09:35:33 Adrian Bunk wrote: > > > The problem with the current "merging" is that it's extremely hard to > > figure out whether some code in x86_64 might be using some code in i386 > > since there are currently 5 (five) different mechanisms used for sharing > > code between the two architectures. > > > > It happens so often that someone accidentally breaks one architecture > > because he didn't notice the code also gets used on the other > > architecture. > > That's not changing at all. Especially with even more sharing, (than I think > would be prudent) like Thomas treated, you'll likely have to test compile both > for most changes. It's not about compilation, it's about seeing that this code might be shared. When e.g. changing a file under arch/i386/kernel/cpu/mtrr/ it's highly surprising that this file might also be used on x86_64. > -Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Saturday 21 July 2007 09:35:33 Adrian Bunk wrote: > The problem with the current "merging" is that it's extremely hard to > figure out whether some code in x86_64 might be using some code in i386 > since there are currently 5 (five) different mechanisms used for sharing > code between the two architectures. > > It happens so often that someone accidentally breaks one architecture > because he didn't notice the code also gets used on the other > architecture. That's not changing at all. Especially with even more sharing, (than I think would be prudent) like Thomas treated, you'll likely have to test compile both for most changes. -Andi - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Sat, Jul 21, 2007 at 08:06:11AM +0200, Andi Kleen wrote: > On Saturday 21 July 2007 07:50:46 Steven Rostedt wrote: > > > This patch was the beginning of the merger, not the end result. It strived > > for binary identical images. It was to put everything together as a > > _starting_point_! The next thing to do after this is to start the > > merging. > > Well we've been merging what makes sense since several years. So it's not > really starting anything that hasn't already occurred. The problem with the current "merging" is that it's extremely hard to figure out whether some code in x86_64 might be using some code in i386 since there are currently 5 (five) different mechanisms used for sharing code between the two architectures. It happens so often that someone accidentally breaks one architecture because he didn't notice the code also gets used on the other architecture. > -Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: [RFC, Announce] Unified x86 architecture, arch/x86
Thomas Gleixner wrote: > We are pleased to announce a project we've been working on for some > time: the unified x86 architecture tree, or "arch/x86" - and we'd like > to solicit feedback about it. > kvm will really like this. while kvm will always have #ifdefs for i386 and x86_64, this work will reduce them, and will make kvm code cleaner. Of course, I also believe it makes sense from the non-kvm-centric point of view. Thanks for doing this! -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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: [RFC, Announce] Unified x86 architecture, arch/x86
> > It's not really the same platform: one is PC hardware going back forever > > with zillions of bugs, the other is modern PC platforms which much less > > bugs and quirks > > hehe, I'm seeing a bunch of bugs and quirks appear. It's just that > x86_64 isn't as old as i386 to have as many of them. But give it time. It will always fundamentally always have less bugs and quirks than i386 because it's much younger. Modern x86 is significantly different than traditional x86 and in the old days hardware wasn't really tested for the now modern interfaces, so they tended to have a lot of bugs and quirks. -Andi - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Saturday 21 July 2007 07:50:46 Steven Rostedt wrote: > This patch was the beginning of the merger, not the end result. It strived > for binary identical images. It was to put everything together as a > _starting_point_! The next thing to do after this is to start the > merging. Well we've been merging what makes sense since several years. So it's not really starting anything that hasn't already occurred. -Andi - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Sat, 21 Jul 2007, Andi Kleen wrote: > On Saturday 21 July 2007 00:32, Thomas Gleixner wrote: > > We are pleased to announce a project we've been working on for some > > time: the unified x86 architecture tree, or "arch/x86" - and we'd like > > to solicit feedback about it. > > Well you know my position on this. I think it's a bad idea because > it means we can never get rid of any old junk. IMNSHO arch/x86_64 > is significantly cleaner and simpler in many ways than arch/i386 and I would > like to preserve that. Also in general arch/x86_64 is much easier to hack > than arch/i386 because it's easier to regression test and in general > has to care about much less junk. And I don't > know of any way to ever fix that for i386 besides splitting the old > stuff off completely. I have to say honestly that it is much easier to work in the i386 arch directories than the x86_64. But that may be my own feelings. You seem to have a nice style that you like and think that it is cleaner. But it doesn't really seem much cleaner to me. Somethings I like better with the x86_64 code, and there's somethings I like better with the i386 code. But from a comfort level, I have to go with worknig with the i386 code. > > Besides radical file movements like this are bad anyways. They cause > a big break in patchkits and forward/backwards porting that doesn't > really help anybody. I think it helps a lot of people. Especially those that are trying to add things to _both_ i386 and x86_64. > > > This causes double maintenance > > even for functionality that is conceptually the same for the 32-bit and > > the 64-bit tree. (such as support for standard PC platform architecture > > devices) Not sure what you mean here? I would think that we have this "double maintence" anyway. Fixes that are done in x86_64 probably should also be done in i386. Why have it in two places? > > It's not really the same platform: one is PC hardware going back forever > with zillions of bugs, the other is modern PC platforms which much less > bugs and quirks hehe, I'm seeing a bunch of bugs and quirks appear. It's just that x86_64 isn't as old as i386 to have as many of them. But give it time. > > To see it otherwise it's more a junkification of arch/x86_64 than > a cleanup of arch/i386 -- in fact you didn't really clean up arch/i386 > at all. That was not the point of this patch. This patch was to unify the two so that we can get started on the unification. > > > How did we do it? > > - > > > > As an initial matter, we made it painstakingly sure that the resulting > > .o files in a 32-bit build are bit for bit equal. > > You got not a single line less code duplication then, so i don't really > see the point of this. > Did you read what tglx wrote? The point of this patch was to keep everything the _same_. The fact that not a single line less code duplication is a feature. A great starting point where we can easily trace things back to the current arch separation, as well as move forward in merging the two. -- Steve - 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: [RFC, Announce] Unified x86 architecture, arch/x86
> On Saturday 21 July 2007 01:55, Michal Piotrowski wrote: > > > > I really like this idea - code duplication is a bad thing. > > Did you actually look at the patch? It doesn't have a single line > less duplication than there was before. Everything that could > be easily shared was shared already. > > It's just new window dressing without any real advantages. And did you read what tglx wrote? This patch was the beginning of the merger, not the end result. It strived for binary identical images. It was to put everything together as a _starting_point_! The next thing to do after this is to start the merging. -- Steve - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Saturday 21 July 2007 01:55, Michal Piotrowski wrote: > Hi, > > On 21/07/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > We are pleased to announce a project we've been working on for some > > time: the unified x86 architecture tree, or "arch/x86" - and we'd like > > to solicit feedback about it. > > > > What is this about? > > [..] > > > As usual, comments and suggestions are welcome! > > I really like this idea - code duplication is a bad thing. Did you actually look at the patch? It doesn't have a single line less duplication than there was before. Everything that could be easily shared was shared already. It's just new window dressing without any real advantages. -Andi - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Saturday 21 July 2007 00:32, Thomas Gleixner wrote: > We are pleased to announce a project we've been working on for some > time: the unified x86 architecture tree, or "arch/x86" - and we'd like > to solicit feedback about it. Well you know my position on this. I think it's a bad idea because it means we can never get rid of any old junk. IMNSHO arch/x86_64 is significantly cleaner and simpler in many ways than arch/i386 and I would like to preserve that. Also in general arch/x86_64 is much easier to hack than arch/i386 because it's easier to regression test and in general has to care about much less junk. And I don't know of any way to ever fix that for i386 besides splitting the old stuff off completely. Besides radical file movements like this are bad anyways. They cause a big break in patchkits and forward/backwards porting that doesn't really help anybody. > This causes double maintenance > even for functionality that is conceptually the same for the 32-bit and > the 64-bit tree. (such as support for standard PC platform architecture > devices) It's not really the same platform: one is PC hardware going back forever with zillions of bugs, the other is modern PC platforms which much less bugs and quirks To see it otherwise it's more a junkification of arch/x86_64 than a cleanup of arch/i386 -- in fact you didn't really clean up arch/i386 at all. > How did we do it? > - > > As an initial matter, we made it painstakingly sure that the resulting > .o files in a 32-bit build are bit for bit equal. You got not a single line less code duplication then, so i don't really see the point of this. -Andi - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On 7/20/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: * Jeff Garzik <[EMAIL PROTECTED]> wrote: > I agree with Andi... it's quite nice to be able to leave some > arch/i386 stuff, and not carry it over to arch/x86-64. we can leave those few items in arch/x86 just as much. No need to keep around a legacy tree for that. how about making all files ans directories take _32 or _64 in the name? except the files or dir that are shared. for example: k8_bus.c is only need by 64 ===> change it to k8_bus_64.c mach-generic===> mach-generic_32 YH - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On 7/20/07, Steven Rostedt <[EMAIL PROTECTED]> wrote: > I really like the idea of a unified source tree for the 2 x86 variants. > The technical differences are really small (of course there are > differences, especially in the boot sequence), and striving to unify as > much as possible while having a clean way to do per 32/64 bit parts as > well is something that imo is the right thing. > Not to mention all the paravirt stuff that's going on. Having a single x86 arch to work with would be greatly beneficial to the work being done to port paravirt to x86_64. As for paravirt, it'd really help. As I had the tree lagged behind by so much, a great part of the work now is checking where i386 is, seeing if it applies for 64-bit, and so on. The differences are not so huge, and I'm trying my best to not let them deviate too much. It could mostly be built incrementally. And I bet a huge part of the tree could be like this too: In most places, they are different for no particular reason, just because two people implemented it separately. There'd be a huge effort to bring those differences into an end, but I think I'd pay in future development speed. (not to mention the duplicate bugs linus have already talked about) Way to go, Thomas and Ingo! I am pretty much for it too. -- Glauber de Oliveira Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Sat, 21 Jul 2007, Arnd Bergmann wrote: > On Saturday 21 July 2007, Thomas Gleixner wrote: > > In my experience, it's very helpful to have a single set of header > files, and merging the two versions of one header usually exposes > bugs that have been fixed in only one of the two, so you get > to fix actual bugs in the process. This can still be done after the merge tglx did. > > In the s390 merge, I also started out in an attempt to guarantee > unchanged object files, much like what you describe. However, it > turned out that fixing it in the process is actually easier. > Either way, 'diff -D __x86_64__' is a great tool for a start, you > should try it out to see how easy it is to merge a lot of files. > > To put it into perspective, I think the s390 merge was a lot easier > than the x86 merge, because there is only a very limited set of > hardware configurations for s390 compared to others. We ended up > doing the full merge with three people within less than a week > and no separate files at all. This is the big reason they wanted to keep it binary identical. Since there are just way too many different configs out there in the x86 world > > OTOH, the powerpc merge is now going into its third year, mostly > because it was started with the intention to remove all cruft > in the process and to only allow sane code into the new architecture. I'd expect x86 to move much faster, just because there are more developers and users of x86 PCs than there are for powerpc. > > The steps that I'd suggest instead are: > > * merge all exported header files of the two architectures. This > alone is a worthy goal, because it allows us to get rid of > the ugly code for deciding which version to use in installed > headers and elsewhere. I don't see why this can't be done after the first "Big" merge. > > * Create an arch/x86/Makefile that descends into ../i386/* and > ../x86_64/* instead of its subdirectories. The thing that Thomas pointed out, is that physical location of the source actually does matter. Having two files side by side with the same name except for a _32.c and _64.c, makes a developer want to merge them. A perfect example is looking at both arch/x86/kernel/module_{32,64}.c One would be encouraged to make that into a single file. But having a arch/i386/kernel/module.c and a arch/x86_64/kernel/module.c would take some time before anyone would care. > > * Merge the arch/x86/* subdirectories, one at a time, starting with > the low-hanging fruit like oprofile or pci, and do the hard > ones like mm and kernel last. Your looking at a 10year plus merge with that approach. I think that is exactly what Ingo and Thomas _dont_ want. Doing it as the big bang way as is posted in this patch is the fastest way to get where we want to go. > > Unfortunately, I don't think I'll spend much time on this, so I > don't get to decide on it, but you asked for feedback ;-) > I'm actually looking forward to helping out here ;-) -- Steve - 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: [RFC, Announce] Unified x86 architecture, arch/x86
Thomas Gleixner wrote: > [...] > As usual, comments and suggestions are welcome! Compiles and boots fine here ( on my Dell Precision WorkStation 530 MT ). And nothing broke so far. I only got some Kconfig warnings[1] with my config[2] but that is. ( I don't know whatever this matter but it boots 7,52 seconds faster as current git head ) [1]http://194.231.229.228/linux-x86/warning [2]http://194.231.229.228/linux-x86/config-x86 > > Thomas, Ingo > > Regards, Gabriel C - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Saturday 21 July 2007, Thomas Gleixner wrote: > The topic of sharing more x86 code has been discussed on LKML a number > of times. Various approaches were discussed and we decided to advance > the discussion by implementing a full solution that brings the > transition to a shared tree to completion. Great stuff. I've worked on doing the same for s390 and powerpc in the past, and really think it's the right thing to do. I've even started my own x86 merge two or three times in the past but never got very far because of the quickly moving source. > In this initial implementation the old arch/i386 and arch/x86_64 trees > are removed _immediately_, in the same commit, and all future x86 > development goes on in the new, shared tree. So the transition right now > is one atomic operation. > > As a next step we plan to generate a gradual, fully bisectable, fully > working switchover from the current code to the fully populated > arch/x86 tree. It will result in about 1000-2000 commits. We are > releasing our current solution because it 100% represents the finally > resulting arch/x86 source tree already, and we first wanted to make > sure that the new architecture layout works fine and folks are happy > before we go and do the (even more complex) fine-grained work. I don't think it's really good to do it this way, or maybe I'm still misunderstanding where you're going. If you really want to end up with the exact set of files that you have your tree now, I see absolutely zero point in making it bisectable. On the contrary, there is nothing particularly complicated in it, so once it has seen some amount of testing it can better get merged in one big changeset. I'm just not convinced that it actully is what we want to end up with. In my experience, it's very helpful to have a single set of header files, and merging the two versions of one header usually exposes bugs that have been fixed in only one of the two, so you get to fix actual bugs in the process. In the s390 merge, I also started out in an attempt to guarantee unchanged object files, much like what you describe. However, it turned out that fixing it in the process is actually easier. Either way, 'diff -D __x86_64__' is a great tool for a start, you should try it out to see how easy it is to merge a lot of files. To put it into perspective, I think the s390 merge was a lot easier than the x86 merge, because there is only a very limited set of hardware configurations for s390 compared to others. We ended up doing the full merge with three people within less than a week and no separate files at all. OTOH, the powerpc merge is now going into its third year, mostly because it was started with the intention to remove all cruft in the process and to only allow sane code into the new architecture. The steps that I'd suggest instead are: * merge all exported header files of the two architectures. This alone is a worthy goal, because it allows us to get rid of the ugly code for deciding which version to use in installed headers and elsewhere. * Merge the remaining header files, to end up with a single include/asm-x86 directory. * Come up with a model that integrates the machine type selection of i386 with the way we build things on x86_64. One way would be to make X86_64 another platform next to X86_PC, X86_VOYAGER and the others. * Create an arch/x86/Kconfig that handles the new common configuration * Create an arch/x86/Makefile that descends into ../i386/* and ../x86_64/* instead of its subdirectories. * Merge the arch/x86/* subdirectories, one at a time, starting with the low-hanging fruit like oprofile or pci, and do the hard ones like mm and kernel last. Unfortunately, I don't think I'll spend much time on this, so I don't get to decide on it, but you asked for feedback ;-) Arnd <>< - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On 21/07/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: * Michal Piotrowski <[EMAIL PROTECTED]> wrote: > >We are pleased to announce a project we've been working on for some > >time: the unified x86 architecture tree, or "arch/x86" - and we'd > >like to solicit feedback about it. > > > >What is this about? > [..] > >As usual, comments and suggestions are welcome! > > I really like this idea - code duplication is a bad thing. > > BTW. I don't see any regression here :) cool - could you tell us a bit more about on what type of box you tried it, it is an old P4 (i386) and how wide and versatile the .config is? http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.22-git15/config Ingo Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: [RFC, Announce] Unified x86 architecture, arch/x86
Alan Cox wrote: > On Fri, 20 Jul 2007 18:38:39 -0400 > Jeff Garzik <[EMAIL PROTECTED]> wrote: > >> I agree with Andi... it's quite nice to be able to leave some arch/i386 >> stuff, and not carry it over to arch/x86-64. > > Its easy enough to push that stuff into arch/x86/legacy and have one > subdirectory of stuff to pull in for ancient systems. The other thing is that "legacy" in this context is fungible. No IOMMU was legacy until the Intel x86-64 chips came out, and I can promise you that some legacy code will be necessary once we start seeing VIA and others come out with embedded x86-64. On the other hand, it's pretty bloody safe to assume that we'll never see an x86-64 chip without CPUID, CMOV, FXSAVE, SSE-2, CMPXCHG, etc. -hpa - 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: [RFC, Announce] Unified x86 architecture, arch/x86
* Michal Piotrowski <[EMAIL PROTECTED]> wrote: > >We are pleased to announce a project we've been working on for some > >time: the unified x86 architecture tree, or "arch/x86" - and we'd > >like to solicit feedback about it. > > > >What is this about? > [..] > >As usual, comments and suggestions are welcome! > > I really like this idea - code duplication is a bad thing. > > BTW. I don't see any regression here :) cool - could you tell us a bit more about on what type of box you tried it, and how wide and versatile the .config is? Ingo - 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: [RFC, Announce] Unified x86 architecture, arch/x86
Hi, On 21/07/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote: We are pleased to announce a project we've been working on for some time: the unified x86 architecture tree, or "arch/x86" - and we'd like to solicit feedback about it. What is this about? [..] As usual, comments and suggestions are welcome! I really like this idea - code duplication is a bad thing. BTW. I don't see any regression here :) Thomas, Ingo Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Fri, 20 Jul 2007 18:38:39 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > I agree with Andi... it's quite nice to be able to leave some arch/i386 > stuff, and not carry it over to arch/x86-64. Its easy enough to push that stuff into arch/x86/legacy and have one subdirectory of stuff to pull in for ancient systems. 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/
Re: [RFC, Announce] Unified x86 architecture, arch/x86
On Fri, 20 Jul 2007, Arjan van de Ven wrote: > On Sat, 2007-07-21 at 00:32 +0200, Thomas Gleixner wrote: > > We are pleased to announce a project we've been working on for some > > time: the unified x86 architecture tree, or "arch/x86" - and we'd like > > to solicit feedback about it. > > > > I really like the idea of a unified source tree for the 2 x86 variants. > The technical differences are really small (of course there are > differences, especially in the boot sequence), and striving to unify as > much as possible while having a clean way to do per 32/64 bit parts as > well is something that imo is the right thing. > Not to mention all the paravirt stuff that's going on. Having a single x86 arch to work with would be greatly beneficial to the work being done to port paravirt to x86_64. Way to go, Thomas and Ingo! -- Steve - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Sat, 2007-07-21 at 00:32 +0200, Thomas Gleixner wrote: > We are pleased to announce a project we've been working on for some > time: the unified x86 architecture tree, or "arch/x86" - and we'd like > to solicit feedback about it. I really like the idea of a unified source tree for the 2 x86 variants. The technical differences are really small (of course there are differences, especially in the boot sequence), and striving to unify as much as possible while having a clean way to do per 32/64 bit parts as well is something that imo is the right thing. I'm more than happy to help with this effort, and have people in my group at Intel help test and engineer this as well. The technical approach of first moving (in an automated way) everything into one directory, and then merge pieces one by one is appealing since it can be done incrementally and carefully, while testing the "can we do separate bits" from the start. So in short, way to go, I hope we can get this thing done as soon as possible. Heck it looks like the infrastructure (not the unification) can make it into 2.6.23 merge window still, so that the entire 2.6.23 window can be used to develop merged-functionality pieces... Greetings, Arjan van de Ven - 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: [RFC, Announce] Unified x86 architecture, arch/x86
On Fri, 20 Jul 2007, Jeff Garzik wrote: > Ingo Molnar wrote: > > * Jeff Garzik <[EMAIL PROTECTED]> wrote: > > > > > I agree with Andi... it's quite nice to be able to leave some arch/i386 > > > stuff, and not carry it over to arch/x86-64. > > > > we can leave those few items in arch/x86 just as much. No need to keep > > around a legacy tree for that. > > By extension it makes doing that sort of thing, in general, more difficult. > Which is IMO not desirable. I think it's *much* harder to carry legacy things around in an old tree that almost nobody even uses any more (probably not true yet, but for most of the main developers, I bet it will be true in a year). Especially one that just duplicates 99% of the stuff. There really isn't that much legacy crud. There are things like random quirks, but every time I hear the (theoretical) argument about how much time and effort we save by having it duplicated somewhere else, I think about all the time we definitely waste by fixing the same bug twice (and worry about the cases where we don't). Linus - 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: [RFC, Announce] Unified x86 architecture, arch/x86
Ingo Molnar wrote: * Jeff Garzik <[EMAIL PROTECTED]> wrote: I agree with Andi... it's quite nice to be able to leave some arch/i386 stuff, and not carry it over to arch/x86-64. we can leave those few items in arch/x86 just as much. No need to keep around a legacy tree for that. By extension it makes doing that sort of thing, in general, more difficult. Which is IMO not desirable. Jeff - 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: [RFC, Announce] Unified x86 architecture, arch/x86
* Jeff Garzik <[EMAIL PROTECTED]> wrote: > I agree with Andi... it's quite nice to be able to leave some > arch/i386 stuff, and not carry it over to arch/x86-64. we can leave those few items in arch/x86 just as much. No need to keep around a legacy tree for that. Ingo - 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: [RFC, Announce] Unified x86 architecture, arch/x86
I agree with Andi... it's quite nice to be able to leave some arch/i386 stuff, and not carry it over to arch/x86-64. Jeff - 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/
[RFC, Announce] Unified x86 architecture, arch/x86
We are pleased to announce a project we've been working on for some time: the unified x86 architecture tree, or "arch/x86" - and we'd like to solicit feedback about it. What is this about? --- The topic of sharing more x86 code has been discussed on LKML a number of times. Various approaches were discussed and we decided to advance the discussion by implementing a full solution that brings the transition to a shared tree to completion. Warning: our approach is quite a bit more extreme than what has been suggested before. The core idea behind our project is simple to describe: we introduce a new arch/x86/ and include/asm-x86/ file hierarchy that includes all the existing 32-bit and 64-bit x86 code and allows the building of either a 32-bit (i386) kernel or a 64-bit (x86_64) kernel. In this initial implementation the old arch/i386 and arch/x86_64 trees are removed _immediately_, in the same commit, and all future x86 development goes on in the new, shared tree. So the transition right now is one atomic operation. As a next step we plan to generate a gradual, fully bisectable, fully working switchover from the current code to the fully populated arch/x86 tree. It will result in about 1000-2000 commits. We are releasing our current solution because it 100% represents the finally resulting arch/x86 source tree already, and we first wanted to make sure that the new architecture layout works fine and folks are happy before we go and do the (even more complex) fine-grained work. A git tree is available from: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/linux-2.6-x86.git One (large!) combo patch is available at: http://kernel.org/pub/linux/kernel/people/tglx/linux-x86.2.6.22-git-ede13d.combo.patch.bz2 the patch is against this upstream -git head: commit ede13d81b4dda409a6d271b34b8e2ec9383e255d It makes little sense to apply this patch to anything else because these architectures are such a fast-moving target. Why do we want to do this? -- We believe that the whole x86 CPU family is very much related and should be supported in a single architecture tree. All 64-bit CPUs implement the ability to execute pure 32-bit kernels, and will probably do so for the next couple of decades. So it's not like it will ever be possible to get rid of our legacies: for example even the latest 64-bit CPUs implement the legacy "A20 line" feature that was already a weird outdated hack in the days of 16-bit x8086 CPUs. So what can we do? We should learn to live better with our legacies, and we should avoid reinventing the wheel in 64-bit code. Today there's already some limited code sharing between the i386 and x86_64 trees, but it's quite non-obvious: it's either done via a placeholder file that #include's an out-of-arch file, or a Makefile rule that uses an out-of-arch file. These 'cross-tree' file uses are not visible at the target point, and people sometimes break "the other arch" if they modify the file, because they are not aware of there being code sharing. Furthermore, the separate i386 and x86_64 trees often cause kernel writers to (unconsciously) think in either 32-bit or in 64-bit terms, instead of thinking about the two things in one way. It also happened numerous times that code that was originally copied from arch/i386 gets 64-bit-only additions in arch/x86_64, and if a bug is fixed in the 32-bit code, that fix is not applied to the x86_64 tree. Or some function is cleaned up and improved in the x86_64 tree, but that improvement is not easily adaptable to arch/i386, because the x86_64 code became 64-bit only already. All in one: the two architecture trees are "way too far apart" from each other, which causes the source code to diverge not only physically but structurally as well. The whole setup works _against_ sharing code, instead of working _for_ sharing code. This causes double maintenance even for functionality that is conceptually the same for the 32-bit and the 64-bit tree. (such as support for standard PC platform architecture devices) How did we do it? - As an initial matter, we made it painstakingly sure that the resulting .o files in a 32-bit build are bit for bit equal. (at least in terms of .text, small .data differences are there due to the namespace changes). We also made it sure that you can pick up _any_ existing 32-bit .config, stick it into our new arch/x86 tree and build a fully working 32-bit kernel. Same is the goal for any existing 64-bit .config as well. The shared x86 tree is _not_ "merge the 32-bit legacy code into the x86_64 tree". It is _not_ "create a x86_64 tree that can run on modern 32-bit hardware too, leave arch/i386 around for ancient stuff". It is a unification between equals, all legacies and all new code is unified into one shared tree. Nothing is left behind. A key component of our change is that only a very small portion of the conversion was don