linux-mips-fnet
[Top] [All Lists]

Re: GNU libc sources

To: linux-mips@fnet.fr
Subject: Re: GNU libc sources
From: Dom Sweetman <dom@algor.co.uk>
Date: Tue, 27 May 1997 15:24:57 +0100 (BST)
In-reply-to: <199705271332.PAA03275@informatik.uni-koblenz.de>
References: <199705270658.HAA00197@gladsmuir.algor.co.uk> <199705271332.PAA03275@informatik.uni-koblenz.de>
Ralf wrote:

> the general problem that we have under Linux is that the way the Linux
> device drivers for shared memory and DMA hardware on ISA/EISA/PCI bus
> are implemented is not really suitable for use on a MIPS system.
> 
> The reason for this is easy; the Linux device drivers were originally
> written on for Intel where virtual and physical addresses are the same.
> ...
> Nothing however has so far been done to support DMA cache coherence in
> software because Intel and Alpha solve this in hardware invisible to
> the programmer.

We've notice (as gray-haired BSD folk at heart) that Linux sometimes
is very PC-centric.  But if you want Linux to be portable, you'd
better work towards losing these two assumptions; and not just in
'ifdefs' either.  Even Intel might ship a Merced one day.

You *can* write a successful OS where virtual and physical are related
in a more complex way; and you can cope with driver-visible caches.

In fact, the MIPS approach has a lot to recommend it.  As well as
making the hardware simpler, it's often more efficient for the CPU to
writeback or invalidate the cache - the hardware poking from the other
side ends up shutting the CPU out of the cache while it does the job.

It's an interesting question how the "mainstream" Linux camp would
react to the idea that this is a portable coding practice question,
which is everybody's problem.  Many useful memory systems are a lot
more complicated than a PC-clone forget-the-cache approach can
support; it's not just MIPS.

Random points:

I can't see how anything you do at kmalloc() time is going to fix the
problem. 

I decided a couple of manuals back that I'd give up using the term
"cache flush" because I was never sure whether I (or anyone else)
meant "invalidate" or "writeback" or both.

> ... it might also make sense to have a portable way to flush caches.
> For that I suggest an hook similar to the other cache flushing
> functions.

You really need two functions:

  writeback (addr, n)

which on a vanilla MIPS machine would write back n bytes worth of
locations from addr, and

  invalidate (addr, n)

which would invalidate n bytes worth of locations from addr.  Whether
these are physical or virtual addresses doesn't matter much, so long
as you decide which and don't change your mind!  My preference would
be to work in the kernel's normal address space for as long as
possible, and provide a function for drivers wanting to calculate
physical addresses...

However, you wouldn't actually usually write those in drivers; you'd
code them as:

  before_dma_out (addr, n) == writeback on MIPS
  after_dma_in (addr, n)   == invalidate on MIPS

On a PC clone, both "before..." and "after..." can be ifdef'd away.

Dominic Sweetman
Algorithmics Ltd
dom@algor.co.uk

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