Hi,
Any particular reasons why a stock 2.4.3 kernel doesn't have mm.h and
pgalloc.h in sync on Alpha. This is what I get :
# make boot
gcc -D__KERNEL__ -I/usr/src/redhat/linux/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe
-mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6 -c -o init/main.o
init/main.c
In file included from /usr/src/redhat/linux/include/linux/highmem.h:5,
from /usr/src/redhat/linux/include/linux/pagemap.h:16,
from /usr/src/redhat/linux/include/linux/locks.h:8,
from /usr/src/redhat/linux/include/linux/raid/md.h:36,
from init/main.c:24:
/usr/src/redhat/linux/include/asm/pgalloc.h:334: conflicting types for
`pte_alloc'
/usr/src/redhat/linux/include/linux/mm.h:399: previous declaration of
`pte_alloc'
/usr/src/redhat/linux/include/asm/pgalloc.h:352: conflicting types for
`pmd_alloc'
/usr/src/redhat/linux/include/linux/mm.h:412: previous declaration of
`pmd_alloc'
make: *** [init/main.o] Error 1
2.4.1 compiled fine, and as far as I can see, some changes has been made
to mm.h since then. I think these changes was followed up by i386, ppc,
s390 and sparc64 kernels but not on others. Any plans on when this is
done ?
Best regards,
--
Steffen Persvold Systems Engineer
Email : mailto:[email protected] Scali AS (http://www.scali.com)
Tlf : (+47) 22 62 89 50 Olaf Helsets vei 6
Fax : (+47) 22 62 89 51 N-0621 Oslo, Norway
> `pmd_alloc'
> /usr/src/redhat/linux/include/linux/mm.h:412: previous declaration of
> `pmd_alloc'
> make: *** [init/main.o] Error 1
>
>
> 2.4.1 compiled fine, and as far as I can see, some changes has been made
> to mm.h since then. I think these changes was followed up by i386, ppc,
> s390 and sparc64 kernels but not on others. Any plans on when this is
> done ?
Its fixed in the -ac tree but I've yet to push that set of changes to Linus
Hi All, Alan,
I realize I don't keep up with the linux kernel mailing list like i should but
the change to pmd_alloc and pte_alloc has me a little worried.
I'm working on the ppc64 port (sources soon to be posted) and this change
affects one of the design attributes that we've had.
Basically in the pmd, it would seem that the current design in 2.4.3 forces
you to have pointers in there. Currently in our source we're using offsets
instead of a 64 bit pointer... this of course saved us from having to alloc 2
contiguous pages in memory.
This isn't the end of the world, we can change over to using pointers but I
just wanted to confirm that that was the intent or maybe I'm missing something
and there is still a way out and still have our own arch dependant
implementations of pte_alloc and pmd_alloc.
Regards,
Tom
Alan Cox wrote:
>
> > `pmd_alloc'
> > /usr/src/redhat/linux/include/linux/mm.h:412: previous declaration of
> > `pmd_alloc'
> > make: *** [init/main.o] Error 1
> >
> >
> > 2.4.1 compiled fine, and as far as I can see, some changes has been made
> > to mm.h since then. I think these changes was followed up by i386, ppc,
> > s390 and sparc64 kernels but not on others. Any plans on when this is
> > done ?
>
> Its fixed in the -ac tree but I've yet to push that set of changes to Linus
--
Tom Gall - PowerPC Linux Team "Where's the ka-boom? There was
Linux Technology Center supposed to be an earth
(w) [email protected] shattering ka-boom!"
(w) 507-253-4558 -- Marvin Martian
(h) [email protected]
http://oss.software.ibm.com/developerworks/opensource/linux
[email protected] writes:
> Basically in the pmd, it would seem that the current design in 2.4.3 forces
> you to have pointers in there. Currently in our source we're using offsets
> instead of a 64 bit pointer... this of course saved us from having to alloc 2
> contiguous pages in memory.
Nope, the representation of the pgd/pmd/pte entries is entirely up to
you (us :). The pmd entries for example are accessed through pmd_none,
pmd_present, pte_offset, etc., and are set with pmd_populate. Those
functions are all defined in asm/pgtable.h and asm/pgalloc.c. So you
can make the representation whatever you like as long as those
functions all do the right thing. Same goes for the pgd and pte
levels.
Paul.