Re: [PATCH 0/11 v3] enable "make ARCH=x86"
Hi, On Fri, 9 Nov 2007, Jeff Garzik wrote: > > > I switch between other cross-compiled arches (alpha, usually) on the > > > makefile command line > > > > > > Yes, I know other 32/64-bit arches require .config editing. That > > > doesn't change the basic fact that this is a workflow regression. > > > > > > Jeff > > > > You can use: > > > > make i386_defconfig > > make x86_64_defconfig > > Does that work for alpha too? > > > > In any other case you'd be editing the .config anyways. > > No, that's a logic rathole down which I will not follow :) > > You can make any argument along those lines command line usage is really an > art, not a science. Its a user interface, and that involves human taste > rather than logic. > > I've been bouncing between architectures using ARCH= for years, and my fingers > and brain have been trained. It's just disappointing and a pain to change > this nice user interface that has served so well for years. I disagree that this is a regression. You can still bounce between archs as before, but the fact is that these are not separate archs anymore. The sooner we'll get used to the fact the better. You also don't bounce between archs just by changing ARCH, you also have to reconfigure the kernel and that's there you can change the 64bit option. This means for the normal user not much is changing and from an experienced user I'd expect to know the difference. If we look at this as a new feature, we have to look at what is needed to support this properly. Should the arch name imply certain config options? This wouldn't have to be limited to 64BIT - SMP or MMU could be other options. I think it would also make sense to hide the corresponding config option, otherwise one could change an option, which is a little later ignored anyway. Another question would be if and how it affects other information like uname information. What I'd like to avoid is to add potential cruft, which is only used to avoid the inevitable to properly learn how to configure the kernel. A user interface has a lot to do with logic, especially consistency - an inconsistent mess also doesn't taste very good. bye, Roman - 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: [PATCH 0/11 v3] enable "make ARCH=x86"
Sam Ravnborg wrote:
> With this patchset the former ARCH=i386 / ARCH=x86_64 are
> replaced by ARCH=x86.
[...]
> x86: drop backward compatibility symlinks to i386/boot and
>
> The fist kill the symlinks to bzImage.
> Now that we changed everything else to x86 there is no reason to
> keep the backward compatibility symlinks
> It is now people know we are unifying {i386,x86_64}=>x86 so the
> will not be too suprised seeing some breakage.
> If we do not kill the symlinks now - then when..
This was discussed before [1] and the result then was that the symlinks
should be kept for a while (Alan even suggested "a couple of years").
In fact, they were added exactly for that reason.
For one thing, this change is known to break Debian kernel builds using
kernel-package, a method I use myself to build from current git for testing.
I have so far not filed a bug report against kernel-package because there
was still discussion going on as to how things would look and IMO it's
better to change build tools once things have been finalized then trying to
keep up with a moving target.
Breaking kernel-package (and possibly other similar tools) by removing the
compat symlinks too early may mean less testing of kernels by people like me.
Cheers,
Frans Pop
P.S. The ARCH=x86 change would not have broken kernel-package as that could
be worked around using its cross-compilation options. And it currently looks
like the old options will be preserved anyway.
[1] http://lkml.org/lkml/2007/10/26/31
-
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: [PATCH 0/11 v3] enable "make ARCH=x86"
Theodore Tso <[EMAIL PROTECTED]> wrote: > On Sat, Nov 10, 2007 at 12:35:01PM -0800, H. Peter Anvin wrote: >> In fact, we should be able to get rid of ARCH entirely; CONFIG_ options >> have the huge advantage that they're saved in a file, and you don't have to >> type them on every make run. The only option that I can't see us getting >> rid of easily is HOSTCC, since it is used before config is run, but >> probably something clever can be done there, too. > Yes, please! One of the more annoying things is forgetting the > ARCH=um when rebuilding UML. It would be awfully nice if ARCH was set > via a CONFIG_ option and was persistent. This should have been fixed, or it's about to be fixed. My patch is here: http://groups.google.com/group/linux.kernel/browse_thread/thread/93e5c33fc6e8cff6/39aff558a636ad02 (This patch was superseded by another patch, which may be delayed or mm-only.) OTOH, if you can implement ARCH= using CONFIG_ARCH, why not? Just don't forget to keep the scripts running, and make randconfig only select buildable archs. - 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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Sat, Nov 10, 2007 at 12:35:01PM -0800, H. Peter Anvin wrote: > In fact, we should be able to get rid of ARCH entirely; CONFIG_ options > have the huge advantage that they're saved in a file, and you don't have to > type them on every make run. The only option that I can't see us getting > rid of easily is HOSTCC, since it is used before config is run, but > probably something clever can be done there, too. Yes, please! One of the more annoying things is forgetting the ARCH=um when rebuilding UML. It would be awfully nice if ARCH was set via a CONFIG_ option and was persistent. - Ted - 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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Sat, Nov 10, 2007 at 12:35:01PM -0800, H. Peter Anvin wrote: > > HOWEVER, I think the right thing for allyesconfig, allmodconfig, > randconfig, etc. is to be able to override specific variables. Right > now, one has to use indirection via a file, which is a bit clumsy; it > would be better if one could do "make allyesconfig CONFIG_X86_64=y" or > somesuch. See patch-set I just sent out :-) > > In fact, we should be able to get rid of ARCH entirely; CONFIG_ options > have the huge advantage that they're saved in a file, and you don't have > to type them on every make run. The only option that I can't see us > getting rid of easily is HOSTCC, since it is used before config is run, > but probably something clever can be done there, too. My long term plan is to enable the above. I had planned to do a lot for 2.6.25 but all this x86 stuff have eaten too much time. And I have plenty of kbuild stuff in my inbox awaiting some attention... Sam - 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: [PATCH 0/11 v3] enable "make ARCH=x86"
Paul Mundt wrote: Indeed, that's what I was intending on keeping around as a convention, and simply overloading SRCARCH for the sh64 case. i386/x86_64 potentially has the same issue though, and if the intent is to have a single ARCH for both of them, I don't see how that would possibly work without sacrificing randconfig.. unless the intended x86 convention is that one compiler will happily handle both i386 and x86_64 without any difficulty? Well, that *is* the normal thing on x86. HOWEVER, I think the right thing for allyesconfig, allmodconfig, randconfig, etc. is to be able to override specific variables. Right now, one has to use indirection via a file, which is a bit clumsy; it would be better if one could do "make allyesconfig CONFIG_X86_64=y" or somesuch. In fact, we should be able to get rid of ARCH entirely; CONFIG_ options have the huge advantage that they're saved in a file, and you don't have to type them on every make run. The only option that I can't see us getting rid of easily is HOSTCC, since it is used before config is run, but probably something clever can be done there, too. -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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Sat, Nov 10, 2007 at 12:08:12AM +0100, Sam Ravnborg wrote: > With this patchset the former ARCH=i386 / ARCH=x86_64 are > replaced by ARCH=x86. > The rationale behind the patchset are that with a > unified x86 architecture this should be reflected in > the build commands. > > With this patch set the 32/64 bit selection is done > at configuration time like we know it from parisc and > powerpc. > > Please pull to your cleanup branch: > > ssh://master.kernel.org/pub/scm/linux/kernel/git/sam/x86.git > > I leave it to you (x86 maintainers) to decide when to push this to Linus. > But I strongly suggest sooner is better so we finish the build parts > of the x86 unification. I'll second that request. We should finish off the user-visible parts of the merge in one release (2.6.24). - 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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Sat, 10 Nov 2007, Sam Ravnborg wrote:
Subject: Re: [PATCH 0/11 v3] enable "make ARCH=x86"
In an not opposed to keep ARCH={i386,x86_64} but then we should
establish clear semantics.
What does it imply when I build a kernel with ARCH=i386?
- 32 bit, build kernel, uname -m
as a user I think it would be a good idea to keep the i386/x86_64 options
around for a few kernel revisions to maintain compatibilty with people's
build scripts (not everyone upgrades every kernel release. I've been
running kernel.org kernels in production for over 10 years and between the
scheduler changes in .23 and the arch merge in .24 even I'm going to be
very cautious until .25 or .26 fleshes out all the gotchas, although the
per-device buffer work is valuble enough that a couple systems will get
it soon)
you also need a transition for make oldconfig for several versions
i386 should imply 32 bit and the old CPU i386 options
x86_64 should imply 64 bit and the old amd_64 cpu options
and what about the intuitive version: make ARCH=x86
Is this a 32 or 64 bit kernel?
unknown, which cpu did you select to compile it for? and in the case of
cpus that support both modes, which one did you select? I don't know if
it makes sense to just list K8-32 and K8-64 as seperate cpu options in one
menu or to have a 32/64 bit switch and then two seperate cpu menus (I
suspect the first is better in the long run) but either way can work.
How do we in a generic way say "this is a 64 bt kernel"?
Something that works equally well for s390, ppc, sh, sparc etc?
make ARCH=s39064 looks bad...
make ARCH=sh64 looks OK...
why do you need to have it as a specific command-line option instead of
being part of your cpu selection?
and isn't there something like march=686 that could be extended to
march=k8-32 vs march=k8-64?
march=s390-64 or s390-32 doesn't look nearly as bad as s39064 that you
listed above.
David Lang
-
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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Sat, Nov 10, 2007 at 03:23:32AM -0500, Jeff Garzik wrote:
> Sam Ravnborg wrote:
>> Keeping ARCH=i386 and ARCH=x86_64 around is just a way to pretend
>> this is two diffrent architectures which is no longer the case.
>
> They _are_ different in the real world... that's why
>
> make ARCH=i386
>
> is so often used.
I for one use i386 simply because I do not have any computer that would
support 64bit. But when I'll see a 32/64bit question during
"make oldconfig" I'll also know what to answer.
>> Do we need a way to say "build a kernel that is 64 bit"?
>> If we need this then we should look at the most intuitive way
>> to say so and this should work across x86, powerpc and s390.
>>
>> make 64BIT=y ARCH=x86
>>
>> looks so much more intuitive. And it is generic.
>> This is just a proposal.
>
> Or the short and straightforward
>
> make ARCH=x86_64
>
> to do the same thing (and incidentally what we've been doing up until this
> point).
>
> Don't get so hung up on "architecture" and actually look at what people do
> _today_.
>
> All other solutions proposed are simply _longer_ ways to do exact the same
> thing. "more work for same outcome" isn't optimal.
Let's check who the "people" affected are:
Aunt Tillie isn't affected since she doesn't compile her own kernel.
People compiling kernels have to learn that the choice went from
ARCH={i386,x86_64} to a Kconfig option. I'd say it's more consistent
that the 32/64bit question is now handled the same way as the
K6/K7/K8/... question. And there doesn't seem to be any "longer" or
"more work" in this case.
What's left are kernel developers who have not read the toplevel README
and who do therefore not know about KCONFIG_ALLCONFIG. Getting people to
write documentation is a hard task, but it's only second to getting
people to read documentation
And although you might argue that you have a few characters more to type
when using KCONFIG_ALLCONFIG it has the advantage that it's generic,
and it e.g. allows you to create a CONFIG_X86_32=y, CONFIG_SMP=n
allyesconfig configuration.
> Jeff
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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Sat, Nov 10, 2007 at 03:24:53AM -0500, Jeff Garzik wrote:
> Paul Mundt wrote:
> >This is one of the things I've been wondering about with an sh/sh64
> >unification, as we have no option but having completely different
> >toolchains, and CONFIG_64BIT=y won't work there when they are both
> >using a 32-bit ABI.
>
>
> IMO it seems like you ought to be able to do
>
> make ARCH=sh
> or
> make ARCH=sh64
>
> and have it do the right thing. Ditto for ppc/ppc64, etc.
>
> Sane, straightforward, simple, consistent with existing practice...
Excpet that setting ARCH=... imply more than the 32/64 bit choice.
One other thing is that using ARCH=xxx64 tells people
that the kernel is located in arch/xxx64/boot/
So what is it we want ARCH=xxx to say?
a) the exact architecture to use? (seems not)
b) a good hint about the architecture and a 32/64 bit selector (seems so)
c) part of the location of the build kernel (not discussed)
d) output of `uname -m` (?)
ARCH=xxx
is used for more than the 32/64 bit selection mechanish.
It is in fact an overloaded interface selecting several
things in one go.
And it is not even used consistent across the linux kernel.
Some use it for their generic architecture and later
decide on the bit size. Other let it imply the bit size.
In general a confusing thing that we are now getting used to.
In an not opposed to keep ARCH={i386,x86_64} but then we should
establish clear semantics.
What does it imply when I build a kernel with ARCH=i386?
- 32 bit, build kernel, uname -m
and what about the intuitive version: make ARCH=x86
Is this a 32 or 64 bit kernel?
How do we in a generic way say "this is a 64 bt kernel"?
Something that works equally well for s390, ppc, sh, sparc etc?
make ARCH=s39064 looks bad...
make ARCH=sh64 looks OK...
Sam
-
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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Sat, Nov 10, 2007 at 10:21:41AM +0100, Adrian Bunk wrote: > On Sat, Nov 10, 2007 at 05:21:52PM +0900, Paul Mundt wrote: > > If you do that, then things like randconfigs will randomly break if you > > happen to use a toolchain targetted specifically at i386 or so. > >... > > If you want to know how to restrict randconfig to CONFIG_X86_32 with an > unified architecture you should either read the toplevel README in the > kernel sources or an older email of mine in this thread... > Ah, I missed the KCONFIG_ALLCONFIG stuff, that's what I get for jumping in to the thread late. Thanks for pointing this out, and sorry for the noise! - 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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Sat, Nov 10, 2007 at 05:21:52PM +0900, Paul Mundt wrote: > On Sat, Nov 10, 2007 at 08:54:44AM +0100, Sam Ravnborg wrote: > > On Fri, Nov 09, 2007 at 10:23:23PM -0500, Jeff Garzik wrote: > > > Sam Ravnborg wrote: > > > >This is the patch that get rid of ARCH=i386 and ARCH=x86_64 > > > >and introduce ARCH=x86. > > > >It touches several files but the changes are all one or two-liners. > > > > > > > > x86: drop backward compatibility symlinks to i386/boot and > > > > x86_64/boot > > > > kbuild: sanity check the specified arch > > > > > > > > > IMO it negatives impacts the workflow when you -remove- the ability to > > > set 32/64-bit on the make command line. > > > > > > Building and testing for both architectures now requires the additional > > > step of editing .config, which is a clear workflow negative impact at > > > least for me. > > When it was decided to unify i386 and x86_64 it was at the same time > > decided to handle them as a *single* architecture. > > > > Keeping ARCH=i386 and ARCH=x86_64 around is just a way to pretend > > this is two diffrent architectures which is no longer the case. > > If you do that, then things like randconfigs will randomly break if you > happen to use a toolchain targetted specifically at i386 or so. >... If you want to know how to restrict randconfig to CONFIG_X86_32 with an unified architecture you should either read the toplevel README in the kernel sources or an older email of mine in this thread... 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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Sat, Nov 10, 2007 at 03:24:53AM -0500, Jeff Garzik wrote: > Paul Mundt wrote: > >This is one of the things I've been wondering about with an sh/sh64 > >unification, as we have no option but having completely different > >toolchains, and CONFIG_64BIT=y won't work there when they are both > >using a 32-bit ABI. > > > IMO it seems like you ought to be able to do > > make ARCH=sh > or > make ARCH=sh64 > > and have it do the right thing. Ditto for ppc/ppc64, etc. > > Sane, straightforward, simple, consistent with existing practice... > Indeed, that's what I was intending on keeping around as a convention, and simply overloading SRCARCH for the sh64 case. i386/x86_64 potentially has the same issue though, and if the intent is to have a single ARCH for both of them, I don't see how that would possibly work without sacrificing randconfig.. unless the intended x86 convention is that one compiler will happily handle both i386 and x86_64 without any difficulty? The idea of a single SRCARCH and differing ARCHs for adjusting the build semantics as we have now is quite straightforward and seems clean enough without pushing for ARCH unification. - 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: [PATCH 0/11 v3] enable "make ARCH=x86"
Paul Mundt wrote: This is one of the things I've been wondering about with an sh/sh64 unification, as we have no option but having completely different toolchains, and CONFIG_64BIT=y won't work there when they are both using a 32-bit ABI. IMO it seems like you ought to be able to do make ARCH=sh or make ARCH=sh64 and have it do the right thing. Ditto for ppc/ppc64, etc. Sane, straightforward, simple, consistent with existing practice... 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: [PATCH 0/11 v3] enable "make ARCH=x86"
Sam Ravnborg wrote: Keeping ARCH=i386 and ARCH=x86_64 around is just a way to pretend this is two diffrent architectures which is no longer the case. They _are_ different in the real world... that's why make ARCH=i386 is so often used. Do we need a way to say "build a kernel that is 64 bit"? If we need this then we should look at the most intuitive way to say so and this should work across x86, powerpc and s390. make 64BIT=y ARCH=x86 looks so much more intuitive. And it is generic. This is just a proposal. Or the short and straightforward make ARCH=x86_64 to do the same thing (and incidentally what we've been doing up until this point). Don't get so hung up on "architecture" and actually look at what people do _today_. All other solutions proposed are simply _longer_ ways to do exact the same thing. "more work for same outcome" isn't optimal. 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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Sat, Nov 10, 2007 at 08:54:44AM +0100, Sam Ravnborg wrote: > On Fri, Nov 09, 2007 at 10:23:23PM -0500, Jeff Garzik wrote: > > Sam Ravnborg wrote: > > >This is the patch that get rid of ARCH=i386 and ARCH=x86_64 > > >and introduce ARCH=x86. > > >It touches several files but the changes are all one or two-liners. > > > > > > x86: drop backward compatibility symlinks to i386/boot and > > > x86_64/boot > > > kbuild: sanity check the specified arch > > > > > > IMO it negatives impacts the workflow when you -remove- the ability to > > set 32/64-bit on the make command line. > > > > Building and testing for both architectures now requires the additional > > step of editing .config, which is a clear workflow negative impact at > > least for me. > When it was decided to unify i386 and x86_64 it was at the same time > decided to handle them as a *single* architecture. > > Keeping ARCH=i386 and ARCH=x86_64 around is just a way to pretend > this is two diffrent architectures which is no longer the case. > If you do that, then things like randconfigs will randomly break if you happen to use a toolchain targetted specifically at i386 or so. randconfigs are pretty useful for testing, it would be nice to have a facility to keep these working without having to have a script grep the .config to figure out which toolchain prefix to use. This is one of the things I've been wondering about with an sh/sh64 unification, as we have no option but having completely different toolchains, and CONFIG_64BIT=y won't work there when they are both using a 32-bit ABI. - 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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Saturday 10 November 2007 18:54, Sam Ravnborg wrote: > On Fri, Nov 09, 2007 at 10:23:23PM -0500, Jeff Garzik wrote: > > Sam Ravnborg wrote: > > >This is the patch that get rid of ARCH=i386 and ARCH=x86_64 > > >and introduce ARCH=x86. > > >It touches several files but the changes are all one or two-liners. > > > > > > x86: drop backward compatibility symlinks to i386/boot and > > > x86_64/boot > > > kbuild: sanity check the specified arch > > > > IMO it negatives impacts the workflow when you -remove- the ability to > > set 32/64-bit on the make command line. > > > > Building and testing for both architectures now requires the additional > > step of editing .config, which is a clear workflow negative impact at > > least for me. > > When it was decided to unify i386 and x86_64 it was at the same time > decided to handle them as a *single* architecture. > > Keeping ARCH=i386 and ARCH=x86_64 around is just a way to pretend > this is two diffrent architectures which is no longer the case. > > Do we need a way to say "build a kernel that is 64 bit"? > If we need this then we should look at the most intuitive way > to say so and this should work across x86, powerpc and s390. > > make 64BIT=y ARCH=x86 > > looks so much more intuitive. And it is generic. > This is just a proposal. > > But lets focus on finding a generic solution and not try > to hang around in old habbits. I agree. So long as you can do it easily on the commandline, it's no problem, and we should be consistent (in calling the arch x86). - 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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Fri, Nov 09, 2007 at 10:23:23PM -0500, Jeff Garzik wrote: > Sam Ravnborg wrote: > >This is the patch that get rid of ARCH=i386 and ARCH=x86_64 > >and introduce ARCH=x86. > >It touches several files but the changes are all one or two-liners. > > > > x86: drop backward compatibility symlinks to i386/boot and > > x86_64/boot > > kbuild: sanity check the specified arch > > > IMO it negatives impacts the workflow when you -remove- the ability to > set 32/64-bit on the make command line. > > Building and testing for both architectures now requires the additional > step of editing .config, which is a clear workflow negative impact at > least for me. When it was decided to unify i386 and x86_64 it was at the same time decided to handle them as a *single* architecture. Keeping ARCH=i386 and ARCH=x86_64 around is just a way to pretend this is two diffrent architectures which is no longer the case. Do we need a way to say "build a kernel that is 64 bit"? If we need this then we should look at the most intuitive way to say so and this should work across x86, powerpc and s390. make 64BIT=y ARCH=x86 looks so much more intuitive. And it is generic. This is just a proposal. But lets focus on finding a generic solution and not try to hang around in old habbits. I can certainly look into enabling a generic syntax but that is a bit down on my TODO list (and most items above this has something to do with the kids and not Linux btw). If we go for the proposed syntax then it should be a matter of teaching kconfig to look for "64BIT" and set the 64BIT symbol accordingly. And thenthe Kconfig files needs to be modified so the they use "64BIT" to select between kernel bit size. Sam - 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: [PATCH 0/11 v3] enable "make ARCH=x86"
Brian Gerst wrote: Jeff Garzik wrote: Sam Ravnborg wrote: This is the patch that get rid of ARCH=i386 and ARCH=x86_64 and introduce ARCH=x86. It touches several files but the changes are all one or two-liners. x86: drop backward compatibility symlinks to i386/boot and x86_64/boot kbuild: sanity check the specified arch IMO it negatives impacts the workflow when you -remove- the ability to set 32/64-bit on the make command line. Building and testing for both architectures now requires the additional step of editing .config, which is a clear workflow negative impact at least for me. I switch between other cross-compiled arches (alpha, usually) on the makefile command line Yes, I know other 32/64-bit arches require .config editing. That doesn't change the basic fact that this is a workflow regression. Jeff You can use: make i386_defconfig make x86_64_defconfig Does that work for alpha too? In any other case you'd be editing the .config anyways. No, that's a logic rathole down which I will not follow :) You can make any argument along those lines command line usage is really an art, not a science. Its a user interface, and that involves human taste rather than logic. I've been bouncing between architectures using ARCH= for years, and my fingers and brain have been trained. It's just disappointing and a pain to change this nice user interface that has served so well for years. This is /not/ a cleanup, it's a user interface change. 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: [PATCH 0/11 v3] enable "make ARCH=x86"
Jeff Garzik wrote: > Sam Ravnborg wrote: >> This is the patch that get rid of ARCH=i386 and ARCH=x86_64 >> and introduce ARCH=x86. >> It touches several files but the changes are all one or two-liners. >> >> x86: drop backward compatibility symlinks to i386/boot and >> x86_64/boot >> kbuild: sanity check the specified arch > > > IMO it negatives impacts the workflow when you -remove- the ability to > set 32/64-bit on the make command line. > > Building and testing for both architectures now requires the additional > step of editing .config, which is a clear workflow negative impact at > least for me. > > I switch between other cross-compiled arches (alpha, usually) on the > makefile command line > > Yes, I know other 32/64-bit arches require .config editing. That > doesn't change the basic fact that this is a workflow regression. > > Jeff You can use: make i386_defconfig make x86_64_defconfig In any other case you'd be editing the .config anyways. -- 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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Fri, Nov 09, 2007 at 10:23:23PM -0500, Jeff Garzik wrote: > Sam Ravnborg wrote: >> This is the patch that get rid of ARCH=i386 and ARCH=x86_64 >> and introduce ARCH=x86. >> It touches several files but the changes are all one or two-liners. >> >> x86: drop backward compatibility symlinks to i386/boot and x86_64/boot >> kbuild: sanity check the specified arch > > > IMO it negatives impacts the workflow when you -remove- the ability to set > 32/64-bit on the make command line. > > Building and testing for both architectures now requires the additional > step of editing .config, which is a clear workflow negative impact at least > for me. > > I switch between other cross-compiled arches (alpha, usually) on the > makefile command line > > Yes, I know other 32/64-bit arches require .config editing. That doesn't > change the basic fact that this is a workflow regression. With KCONFIG_ALLCONFIG you can avoid the editing of the .config and set 32/64-bit on the make command line - and it's not limited to the 32/64-bit choice: $ cat /home/jeff/myi386config CONFIG_HIGHMEM64G=y CONFIG_X86_32=y CONFIG_SMP=n CONFIG_PCI=n CONFIG_IPV6=m $ make allyesconfig KCONFIG_ALLCONFIG=/home/jeff/myi386config > Jeff 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: [PATCH 0/11 v3] enable "make ARCH=x86"
On Fri, 09 Nov 2007 22:23:23 -0500 Jeff Garzik wrote: > Sam Ravnborg wrote: > > This is the patch that get rid of ARCH=i386 and ARCH=x86_64 > > and introduce ARCH=x86. > > It touches several files but the changes are all one or two-liners. > > > > x86: drop backward compatibility symlinks to i386/boot and x86_64/boot > > kbuild: sanity check the specified arch > > > IMO it negatives impacts the workflow when you -remove- the ability to > set 32/64-bit on the make command line. > > Building and testing for both architectures now requires the additional > step of editing .config, which is a clear workflow negative impact at > least for me. > > I switch between other cross-compiled arches (alpha, usually) on the > makefile command line > > Yes, I know other 32/64-bit arches require .config editing. That > doesn't change the basic fact that this is a workflow regression. Thanks. Well said. I strongly agree. --- ~Randy - 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: [PATCH 0/11 v3] enable "make ARCH=x86"
Sam Ravnborg wrote: This is the patch that get rid of ARCH=i386 and ARCH=x86_64 and introduce ARCH=x86. It touches several files but the changes are all one or two-liners. x86: drop backward compatibility symlinks to i386/boot and x86_64/boot kbuild: sanity check the specified arch IMO it negatives impacts the workflow when you -remove- the ability to set 32/64-bit on the make command line. Building and testing for both architectures now requires the additional step of editing .config, which is a clear workflow negative impact at least for me. I switch between other cross-compiled arches (alpha, usually) on the makefile command line Yes, I know other 32/64-bit arches require .config editing. That doesn't change the basic fact that this is a workflow regression. 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/
[PATCH 0/11 v3] enable "make ARCH=x86"
With this patchset the former ARCH=i386 / ARCH=x86_64 are
replaced by ARCH=x86.
The rationale behind the patchset are that with a
unified x86 architecture this should be reflected in
the build commands.
With this patch set the 32/64 bit selection is done
at configuration time like we know it from parisc and
powerpc.
Please pull to your cleanup branch:
ssh://master.kernel.org/pub/scm/linux/kernel/git/sam/x86.git
I leave it to you (x86 maintainers) to decide when to push this to Linus.
But I strongly suggest sooner is better so we finish the build parts
of the x86 unification.
It has been asked: what about "make ARCH=x86_64 allmodconfig"
Here Adrian posted the receipe:
$ cat myconfig
CONFIG_X86_32=n
CONFIG_X86_64=y
$ make allmodconfig KCONFIG_ALLCONFIG=myconfig
Not a simple as before but far more powerfull.
The patchset does not only enable ARCH=x86 but is also
a nice cleanup as the diffstat tells us:
15 files changed, 579 insertions(+), 1173 deletions(-)
The majority of the changes are due to the unification
the Kconfig files for 32 and 64 bit.
The shortlog is here:
x86: unification of cfufreq/Kconfig
x86: start unification of arch/x86/Kconfig.*
x86: arch/x86/Kconfig.cpu unification
x86: add X86_32 dependency to i386 specific symbols in Kconfig.i386
x86: add X86_64 dependency to x86_64 specific symbols in Kconfig.x86_64
x86: copy x86_64 specific Kconfig symbols to Kconfig.i386
x86: move all simple arch settings to Kconfig
x86: move the rest of the menu's to Kconfig
The first 8 patches are just unification of the Kconfig files.
All comments from previous postings has been incorporated.
x86: enable "make ARCH=x86"
This is the patch that get rid of ARCH=i386 and ARCH=x86_64
and introduce ARCH=x86.
It touches several files but the changes are all one or two-liners.
x86: drop backward compatibility symlinks to i386/boot and x86_64/boot
kbuild: sanity check the specified arch
The last two patches are nice bonus patches.
The fist kill the symlinks to bzImage.
Now that we changed everything else to x86 there is no reason to
keep the backward compatibility symlinks
It is now people know we are unifying {i386,x86_64}=>x86 so the
will not be too suprised seeing some breakage.
If we do not kill the symlinks now - then when..
The last patch is a simple sanity check that make sure the
specified ARCH is valid - and hints that x86 is now used.
I have doen a limited number of builds here at home - all with success.
And others have reported success with the previous patchset.
The full diffstat:
Makefile |9 +-
arch/x86/{Kconfig.i386 => Kconfig} | 570 ++---
arch/x86/Kconfig.cpu | 121 ++--
arch/x86/Kconfig.x86_64| 839
arch/x86/Makefile |6 +-
arch/x86/Makefile_32 |2 -
arch/x86/Makefile_64 |2 -
arch/x86/boot/Makefile |6 +-
arch/x86/boot/cpucheck.c |6 -
arch/x86/kernel/Makefile_32|3 +-
arch/x86/kernel/Makefile_64|2 +
.../x86/kernel/cpu/cpufreq/{Kconfig_32 => Kconfig} | 69 ++-
arch/x86/kernel/cpu/cpufreq/Kconfig_64 | 108 ---
arch/x86/vdso/Makefile |2 +-
scripts/kconfig/Makefile |7 +-
15 files changed, 579 insertions(+), 1173 deletions(-)
Patches follow and will be sent to lkml only.
Sam
-
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/
