Hi all,
Lots (if not all) of the arm builds failed for next-20100802 with these
errors:
arch/arm/mm/init.c: In function 'arm_bootmem_init':
arch/arm/mm/init.c:184: error: implicit declaration of function 'memblock_start_pfn'
arch/arm/mm/init.c:186: error: implicit declaration of function 'memblock_end_pfn'
arch/arm/mm/init.c:188: error: implicit declaration of function 'memblock_size_bytes'
Caused by commit 53e16bfaf19346f59b3502e207aa66c61332075c ("memblock:
Introduce for_each_memblock() and new accessors, and use it") interacting
with commit 2778f62056ada442414392d7ccd41188bb631619 ("ARM: initial LMB
trial") and some others from the arm tree.
Ben, is there no way to retain the old APIs while creating the new ones?
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Tue, Aug 03, 2010 at 02:23:10AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Lots (if not all) of the arm builds failed for next-20100802 with these
> errors:
>
> arch/arm/mm/init.c: In function 'arm_bootmem_init':
> arch/arm/mm/init.c:184: error: implicit declaration of function 'memblock_start_pfn'
> arch/arm/mm/init.c:186: error: implicit declaration of function 'memblock_end_pfn'
> arch/arm/mm/init.c:188: error: implicit declaration of function 'memblock_size_bytes'
>
> Caused by commit 53e16bfaf19346f59b3502e207aa66c61332075c ("memblock:
> Introduce for_each_memblock() and new accessors, and use it") interacting
> with commit 2778f62056ada442414392d7ccd41188bb631619 ("ARM: initial LMB
> trial") and some others from the arm tree.
Please, no, don't break the memblock code now. I'm not reworking the
ARM implementation just as the merge window has opened - especially
as the ARM implementation has now been pulled into other people's
trees.
If there's changes to memblock which haven't been in linux-next (which,
as this is a new failure, that is most definitely the case), then they
shouldn't be going into this merge window.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Hi all,
On Tue, 3 Aug 2010 02:23:10 +1000 Stephen Rothwell <[email protected]> wrote:
>
> Caused by commit 53e16bfaf19346f59b3502e207aa66c61332075c ("memblock:
> Introduce for_each_memblock() and new accessors, and use it") interacting
> with commit 2778f62056ada442414392d7ccd41188bb631619 ("ARM: initial LMB
> trial") and some others from the arm tree.
That same memblock commit broke the sh builds like this:
c1: warnings being treated as errors
arch/sh/mm/init.c: In function 'bootmem_init_one_node':
arch/sh/mm/init.c:227: error: unused variable 'i'
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On 08/02/2010 09:28 AM, Russell King wrote:
> On Tue, Aug 03, 2010 at 02:23:10AM +1000, Stephen Rothwell wrote:
>> Hi all,
>>
>> Lots (if not all) of the arm builds failed for next-20100802 with these
>> errors:
>>
>> arch/arm/mm/init.c: In function 'arm_bootmem_init':
>> arch/arm/mm/init.c:184: error: implicit declaration of function 'memblock_start_pfn'
>> arch/arm/mm/init.c:186: error: implicit declaration of function 'memblock_end_pfn'
>> arch/arm/mm/init.c:188: error: implicit declaration of function 'memblock_size_bytes'
>>
>> Caused by commit 53e16bfaf19346f59b3502e207aa66c61332075c ("memblock:
>> Introduce for_each_memblock() and new accessors, and use it") interacting
>> with commit 2778f62056ada442414392d7ccd41188bb631619 ("ARM: initial LMB
>> trial") and some others from the arm tree.
>
> Please, no, don't break the memblock code now. I'm not reworking the
> ARM implementation just as the merge window has opened - especially
> as the ARM implementation has now been pulled into other people's
> trees.
>
> If there's changes to memblock which haven't been in linux-next (which,
> as this is a new failure, that is most definitely the case), then they
> shouldn't be going into this merge window.
>
Ben, what's your tack on this?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Mon, 2010-08-02 at 09:32 -0700, H. Peter Anvin wrote:
> > Please, no, don't break the memblock code now. I'm not reworking the
> > ARM implementation just as the merge window has opened - especially
> > as the ARM implementation has now been pulled into other people's
> > trees.
> >
> > If there's changes to memblock which haven't been in linux-next (which,
> > as this is a new failure, that is most definitely the case), then they
> > shouldn't be going into this merge window.
> >
>
> Ben, what's your tack on this?
I'm perfectly happy to wait for the next merge window.. or even delay it
a bit til we can make sure ARM stuff is in, then memblock is updated to
also update ARM.
The latest failure is a bit of a concern... it shows that sh and
microblaze have not tested the series when I asked them to a while back
then, but then, I suppose everybody is short on time.
In any case, I'll fixup those glitches in my memblock branch, and we can
look at the ARM situation then and decide what to do.
Cheers,
Ben.
On Tue, 2010-08-03 at 02:23 +1000, Stephen Rothwell wrote:
>
> Lots (if not all) of the arm builds failed for next-20100802 with these
> errors:
>
> arch/arm/mm/init.c: In function 'arm_bootmem_init':
> arch/arm/mm/init.c:184: error: implicit declaration of function 'memblock_start_pfn'
> arch/arm/mm/init.c:186: error: implicit declaration of function 'memblock_end_pfn'
> arch/arm/mm/init.c:188: error: implicit declaration of function 'memblock_size_bytes'
>
> Caused by commit 53e16bfaf19346f59b3502e207aa66c61332075c ("memblock:
> Introduce for_each_memblock() and new accessors, and use it") interacting
> with commit 2778f62056ada442414392d7ccd41188bb631619 ("ARM: initial LMB
> trial") and some others from the arm tree.
>
> Ben, is there no way to retain the old APIs while creating the new ones?
I'll have a second look. It might be doable if it's only those 3
functions.
In any case, I'm happy to delay that, wait for ARM to go in, then sent a
new batch that also fixes ARM up.
Once those patches are in, we get some saner APIs to memblocks which
make it a lot easier to rewrite the core, which I think Peter want to do
(and I like his ideas of using a single list very much too).
Cheers,
Ben.
> Please, no, don't break the memblock code now. I'm not reworking the
> ARM implementation just as the merge window has opened - especially
> as the ARM implementation has now been pulled into other people's
> trees.
>
> If there's changes to memblock which haven't been in linux-next (which,
> as this is a new failure, that is most definitely the case), then they
> shouldn't be going into this merge window.
I'm happy to wait and sit on the memblock churn until after ARM's in.
I can then fixup my patches.
Cheers,
Ben.
On 08/02/2010 06:42 PM, Benjamin Herrenschmidt wrote:
>
> I'm happy to wait and sit on the memblock churn until after ARM's in.
>
> I can then fixup my patches.
>
As far as x86 is concerned, I would like to try to get the whole thing
into -tip fairly early in a kernel cycle, so that it can get -tip/-next
testing for a while before merging.
I would much rather smoke out bugs like the qla2xxx failing to implement
.shutdown and therefore doing DMA on random memory than just paper it
over by functionally re-implementing a bunch of the memblock guts in x86.
I still think that the memblock approach of having a separate data
structure for all of memory and one for various used blocks is flawed,
and that it would be a lot better to have a single data structure with
attributes. It would definitely make allocation saner. Given that,
there is a strong reason to keep as little of the guts exposed as possible.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Mon, 2010-08-02 at 20:13 -0700, H. Peter Anvin wrote:
> I still think that the memblock approach of having a separate data
> structure for all of memory and one for various used blocks is flawed,
> and that it would be a lot better to have a single data structure with
> attributes. It would definitely make allocation saner. Given that,
> there is a strong reason to keep as little of the guts exposed as
> possible.
I agree, and in fact, turning the current implementation into a single
list with attributes wouldn't necessarily be that hard as a first step.
Ben.
* Benjamin Herrenschmidt <[email protected]> wrote:
> > Please, no, don't break the memblock code now. I'm not reworking the
> > ARM implementation just as the merge window has opened - especially
> > as the ARM implementation has now been pulled into other people's
> > trees.
> >
> > If there's changes to memblock which haven't been in linux-next (which,
> > as this is a new failure, that is most definitely the case), then they
> > shouldn't be going into this merge window.
>
> I'm happy to wait and sit on the memblock churn until after ARM's in.
>
> I can then fixup my patches.
Ok, i've zapped it all from -tip.
Thanks,
Ingo