Re: New kernel/resource.c

Roger Gammans (rgammans@computer-surgery.co.uk)
Tue, 3 Aug 1999 20:11:21 +0100

In article <d37lnel8he.fsf@dxplus04.cern.ch>, Jes Sorensen
<Jes.Sorensen@cern.ch> writes
>>>>>> "Russell" == Russell King <rmk@arm.linux.org.uk> writes:
>
>Russell> Jes Sorensen writes:
>>> The only thing that sucks about this is when you have adapters with
>>> the exact same chips on them on both PCI and SBUS and you would
>>> like to write a generic driver which determines at runtime what
>>> type of bus it is on. Having to recompile the same code with new
>>> macros one for sbus and one for pci is evil as well.
>>>
>>> Not sure what the pretty solution is though.
>
>Russell> Exactly the same thing happens on some ARM machines, where we
>Russell> have two different address spaces. One of them is a PC view
>Russell> of the IO devices, which is 0x0000 to 0xffff. The other is
>Russell> for expansion cards and other internal devices, which have
>Russell> bit 31 set.
>
>The problem I am thinking of is more the problem of addressing SBUS
>and PCI shared memory using the same macros.

The way round it I keep thinking of is to have generic scheme like

{read,write}{b,w,l}_resource(resource * res.int offset,
{byte,word,long} *data);

Then indirect through an appropriate function pointer found in the
resource struct.

But this doesn't half slow down what was once a single memory access. So
I can't see us going this route given Linus' previous comments.

Good and generic it is yes, but also nice and slow.

TTFN

-- 
Roger Gammans
"If I have trouble installing Linux, something is wrong. Very wrong."
                -- Linus Torvalds


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/