1:10 p.m.
Attached is a patch that adds 4-level page table support to the
IA-64
architecture. I followed the way PPC used the machdep command line
argument to force it. Since this is truly a CONFIG option on IA-64, I
have also added a routine to parse the required information out of
IKCONFIG if it's available. I'm thinking about requiring IKCONFIG for
LKCD, because it just makes life easer.
As a side note, I decided I hate how everything is piled into defs.h
and separated by ifdefs. Dave, how do you feel about breaking defs.h
up into a header for each arch, i.e. ia64_defs.h, ppc_def.h, etc, and
a small common defs.h?
Thanks,
Troy
Hi Troy,
Nice work...
The only issues I see is that the read_config() and read_config_err()
should probably go into a common file in case we ever need them for
other configuration-related stuff in the future, and couple of the malloc()
error messages in read_config() are cut-and-pasted and refer to
"ia64_memmap".
I'll give it a run against a 3 leveler to make sure nothing breaks.
As far as the defs.h split-up, I have no argument against doing that.
Thanks,
Dave
1:43 p.m.
New subject: [PATCH] IA-64 4-level page table support
On 08/01/06 14:10, Dave Anderson wrote:
The only issues I see is that the read_config() and
read_config_err()
should probably go into a common file in case we ever need them for
other configuration-related stuff in the future.
OK, I'll let you decide where they should land, I try not to venture
to far out of the arch specific areas :-).
and couple of the malloc() error messages in read_config() are
cut-and-pasted and refer to "ia64_memmap".
Doah.. OK, I have attached a fixed version. I have also dome some
extra housekeeping in the read_config function.
I'll give it a run against a 3 leveler to make sure nothing
breaks.
Excellent. I tested it on both so everything should be fine.
Thanks!
Troy
1:46 p.m.
New subject: [PATCH] IA-64 4-level page table support
Troy Heber wrote:
On 08/01/06 14:10, Dave Anderson wrote:
> The only issues I see is that the read_config() and read_config_err()
> should probably go into a common file in case we ever need them for
> other configuration-related stuff in the future.
OK, I'll let you decide where they should land, I try not to venture
to far out of the arch specific areas :-).
> and couple of the malloc() error messages in read_config() are
> cut-and-pasted and refer to "ia64_memmap".
Doah.. OK, I have attached a fixed version. I have also dome some
extra housekeeping in the read_config function.
> I'll give it a run against a 3 leveler to make sure nothing breaks.
Excellent. I tested it on both so everything should be fine.
Thanks!
Troy
OK great.
BTW, I don't have any IKCONFIG-enabled kernel environments
to look at. Does the one you used to query CONFIG_PGTABLE_4
show CONFIG_HZ (or perhaps CONFIG_HZ_100, CONFIG_HZ_250,
and/or CONFIG_HZ_1000)?
Dave
2:02 p.m.
New subject: [PATCH] IA-64 4-level page table support
On 08/01/06 14:46, Dave Anderson wrote:
Does the one you used to query CONFIG_PGTABLE_4 show CONFIG_HZ (or
perhaps CONFIG_HZ_100, CONFIG_HZ_250, and/or CONFIG_HZ_1000)?
On my both my IA-64 and AMD64 2.6.17 boxs I have:
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
Troy
1:59 p.m.
New subject: [PATCH] IA-64 4-level page table support
Troy Heber wrote:
On 08/01/06 14:46, Dave Anderson wrote:
> Does the one you used to query CONFIG_PGTABLE_4 show CONFIG_HZ (or
> perhaps CONFIG_HZ_100, CONFIG_HZ_250, and/or CONFIG_HZ_1000)?
On my both my IA-64 and AMD64 2.6.17 boxs I have:
# CONFIG_HZ_100 is not set
CONFIG_HZ_250=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=250
Troy
So we should be able to add CONFIG_HZ to the parse[] array
in read_config(), and then just do an atoi(val) to get its value?
If you get a minute, can you try that?
Dave
2:20 p.m.
New subject: [PATCH] IA-64 4-level page table support
On 08/01/06 14:59, Dave Anderson wrote:
Troy Heber wrote:
So we should be able to add CONFIG_HZ to the parse[] array
in read_config(), and then just do an atoi(val) to get its value?
Yep, I tried to make the parse routine robust enough to get everything
we care about. I used the NR_CPU case to illustrate.
Don't forget that we also need to update the LIST_SIZE define when
adding an item to the parse list, it's probably a good idea to pull
that out of defs.h and define it right next to the list definition.
If you get a minute, can you try that?
Yep, works fine.
Troy
6692
days inactive
6692
days old
devel@lists.crash-utility.osci.io
5 comments
2 participants
participants (2)
-
Dave Anderson -
Troy Heber