[Top] [All Lists]

Re: get_mmu_context()

To: Warner Losh <>
Subject: Re: get_mmu_context()
Date: Tue, 20 Oct 1998 19:31:16 +0200
In-reply-to: <>; from Warner Losh on Mon, Oct 19, 1998 at 10:07:26PM -0600
References: <> <> <> <> <>
On Mon, Oct 19, 1998 at 10:07:26PM -0600, Warner Losh wrote:

> Wouldn't it be easier to have ld to have variant fixup records?  That
> way you could patch all instances at run time, much like we do when we
> load stuff now...
> You are basically duplicating the functionality of the linker here for
> no good reason.  Actually, besides the non-standard aspect of it,
> there is a good reason: it is easier to hack like this than to do
> battle with the bfd and/or boot blocks to get this to happen. :-)
> It is a way cool hack, don't get me wrong, but it just seems that it
> would be more useful to be generic like that.

Neither compiler, assembler nor linker can solve the problem for us
because it requires knowledge of facts which we usually don't know before
running on the target machine.  On the other side as soon as we run on
the machine we know these details.  They're constants, so why not making
optimal use of them?

As alternative to achieve the same level of efficience imagine the
following configuration dialogue:

# Cache configuration
Does your machine have a second level cache (CONFIG_L2_CACHE) [N/y] y
  Is your CPU an Indy R4600SC or R5000SC (CONFIG_L2_INDY) [N/y]
  l2 linesize (16, 32, 64, 128) [128]
  Split Scache (CONFIG_L2_SPLIT) [N/y] 
  Do your VCE exceptions work (CONFIG_R4000SC_V2) [N/y]
Primary instruction cache linesize (16, 32) [16]
Primary data cache linesize (16, 32) [16]

Oh, there is more fun we'd need to ask for like DRAM controller versions
for Magnums etc.  Cool vomit bag, isn't it ;-)

Things look different for fixed configuration systems like for example
the Cobalt Qube.  But we have to deal with zillion of system variants.

You're right in that things should become more generic and I have ideas
to make them more generic.  For the moment being I don't want to continue
on that since 2.2 is coming soon and more important things are still to do.
That's should however be an interesting 2.3 project.


<Prev in Thread] Current Thread [Next in Thread>