From: Michael Ellerman <michael@ellerman.id.au>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
Paul Mackerras <paulus@samba.org>,
linux-next@vger.kernel.org, Sam Ravnborg <sam@ravnborg.org>,
linuxppc-dev@ozlabs.org
Subject: Re: linux-next: kbuild tree build failure
Date: Thu, 10 Jul 2008 10:51:22 +1000 [thread overview]
Message-ID: <1215651082.13950.7.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0807080437550.6791@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Tue, 2008-07-08 at 04:55 +0200, Roman Zippel wrote:
> Hi,
>
> On Tue, 8 Jul 2008, Michael Ellerman wrote:
>
> > I don't really see why it "doesn't make sense" for users to input 64-bit
> > values, they're configuring addresses for a 64-bit kernel, so some of
> > the values are going to be 64 bit.
>
> Do you really expect users to insert random 64bit addresses without making
> a mistake?
Well yes :) But I think that's because you're thinking of
"end-users" and I'm thinking of "users" like myself - ie. _I_ use
Kconfig and I do expect myself to be able to type a 64-bit address.
> > --- .config.orig 2008-07-08 09:30:00.000000000 +1000
> > +++ .config 2008-07-08 09:30:43.000000000 +1000
> > @@ -370,9 +370,8 @@
> > CONFIG_HOTPLUG_PCI_RPA=m
> > CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> > # CONFIG_HAS_RAPIDIO is not set
> > -CONFIG_PAGE_OFFSET=0xc000000000000000
> > -CONFIG_KERNEL_START=0xc000000002000000
> > -CONFIG_PHYSICAL_START=0x02000000
> > +CONFIG_PAGE_OFFSET=0xc0000000
> > +CONFIG_PHYSICAL_START=0x2000000
>
> Why is this worse? These are constants, you're not supposed to change them
> anyway.
> The remaining values are generated in page.h and should be the same as
> before. If that isn't the case and this patch produces a nonworking
> kernel, I'd like to hear about it.
You're right the built kernel is fine. So it's not a bug, but I think it
is nicer to have the real values in the .config.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Michael Ellerman <michael@ellerman.id.au>
To: Roman Zippel <zippel@linux-m68k.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
linux-next@vger.kernel.org, Paul Mackerras <paulus@samba.org>,
Sam Ravnborg <sam@ravnborg.org>,
linuxppc-dev@ozlabs.org
Subject: Re: linux-next: kbuild tree build failure
Date: Thu, 10 Jul 2008 10:51:22 +1000 [thread overview]
Message-ID: <1215651082.13950.7.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0807080437550.6791@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
On Tue, 2008-07-08 at 04:55 +0200, Roman Zippel wrote:
> Hi,
>
> On Tue, 8 Jul 2008, Michael Ellerman wrote:
>
> > I don't really see why it "doesn't make sense" for users to input 64-bit
> > values, they're configuring addresses for a 64-bit kernel, so some of
> > the values are going to be 64 bit.
>
> Do you really expect users to insert random 64bit addresses without making
> a mistake?
Well yes :) But I think that's because you're thinking of
"end-users" and I'm thinking of "users" like myself - ie. _I_ use
Kconfig and I do expect myself to be able to type a 64-bit address.
> > --- .config.orig 2008-07-08 09:30:00.000000000 +1000
> > +++ .config 2008-07-08 09:30:43.000000000 +1000
> > @@ -370,9 +370,8 @@
> > CONFIG_HOTPLUG_PCI_RPA=m
> > CONFIG_HOTPLUG_PCI_RPA_DLPAR=m
> > # CONFIG_HAS_RAPIDIO is not set
> > -CONFIG_PAGE_OFFSET=0xc000000000000000
> > -CONFIG_KERNEL_START=0xc000000002000000
> > -CONFIG_PHYSICAL_START=0x02000000
> > +CONFIG_PAGE_OFFSET=0xc0000000
> > +CONFIG_PHYSICAL_START=0x2000000
>
> Why is this worse? These are constants, you're not supposed to change them
> anyway.
> The remaining values are generated in page.h and should be the same as
> before. If that isn't the case and this patch produces a nonworking
> kernel, I'd like to hear about it.
You're right the built kernel is fine. So it's not a bug, but I think it
is nicer to have the real values in the .config.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2008-07-10 0:51 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-07 8:40 linux-next: kbuild tree build failure Stephen Rothwell
2008-07-07 8:40 ` Stephen Rothwell
2008-07-07 12:51 ` Sam Ravnborg
2008-07-07 12:51 ` Sam Ravnborg
2008-07-07 13:08 ` Stephen Rothwell
2008-07-07 13:08 ` Stephen Rothwell
2008-07-07 16:13 ` Roman Zippel
2008-07-07 16:13 ` Roman Zippel
2008-07-07 21:01 ` Sam Ravnborg
2008-07-07 23:36 ` Michael Ellerman
2008-07-07 23:36 ` Michael Ellerman
2008-07-08 2:55 ` Roman Zippel
2008-07-08 2:55 ` Roman Zippel
2008-07-10 0:51 ` Michael Ellerman [this message]
2008-07-10 0:51 ` Michael Ellerman
2008-07-10 14:59 ` Roman Zippel
2008-07-10 14:59 ` Roman Zippel
2008-07-14 16:53 ` Milton Miller
2008-07-14 16:53 ` Milton Miller
2008-07-08 21:19 ` Sam Ravnborg
2008-07-10 14:52 ` Roman Zippel
2008-07-25 4:13 ` Stephen Rothwell
2008-07-25 4:13 ` Stephen Rothwell
2008-07-26 10:06 ` Sam Ravnborg
2008-07-26 10:06 ` Sam Ravnborg
2008-07-26 12:40 ` Stephen Rothwell
2008-07-26 12:40 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2008-07-12 22:32 Milton Miller
2008-07-12 22:32 ` Milton Miller
2008-07-12 23:21 ` Roman Zippel
2008-07-12 23:21 ` Roman Zippel
2008-11-25 4:47 Stephen Rothwell
2008-11-25 8:42 ` Sam Ravnborg
2008-11-25 8:58 ` Stephen Rothwell
2008-11-26 4:42 Stephen Rothwell
2008-11-26 21:06 ` Sam Ravnborg
2008-11-26 23:49 ` Stephen Rothwell
2008-12-03 0:36 ` Stephen Rothwell
2008-12-03 9:46 ` Sam Ravnborg
2009-05-05 1:17 Stephen Rothwell
2009-05-05 6:35 ` Jan Beulich
2009-05-05 6:43 ` Sam Ravnborg
2009-05-05 7:04 ` Jan Beulich
2009-06-09 1:48 Stephen Rothwell
2009-06-09 16:15 ` Sam Ravnborg
2009-06-09 16:19 ` Stephen Rothwell
2009-06-09 21:04 ` Sam Ravnborg
2009-06-09 23:27 ` Stephen Rothwell
2009-10-14 1:20 Stephen Rothwell
2009-10-14 7:43 ` Sam Ravnborg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1215651082.13950.7.camel@localhost \
--to=michael@ellerman.id.au \
--cc=linux-next@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=paulus@samba.org \
--cc=sam@ravnborg.org \
--cc=sfr@canb.auug.org.au \
--cc=zippel@linux-m68k.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.