[lkml]   [1999]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: New resources - pls, explain :-(
On Wed, Aug 11, 1999, Alan Cox <> wrote:

>Its cute but if you think harder the implementation would suck
>> right thing" for that bus. One could add "bigendian_writel()" and
>> "littleendian_writel()" to satisfy the Linus constraint of making
>> unusual usage of writel() obvious.
>So every I/O has an if in it. Nothing like stalling the pipeline before we
>probably stall on I/O writes to make things twice as painful.

And what about simply having a struct io_bus containing function pointers
to read/write and ioremap routines ? This way, we could hide all the i/o
range offset issues when using several busses (we do have such problems
with the ppc, especially with IDE, see recent discussion of linuxppc-dev
mailing list). Each driver would have an bus structure associated with
the device, eventually provided by the resource tree, and the only
overhead of i/os could be the indirect function call.

For the endian issue (which I think is a non-issue) , most of the time,
the endian is known at compile time and could get be resolved by macros.
If it's not the case, then just add two sets of i/o function pointers in
the bus structure.

Also, each bus stucture (let's call this a bus driver) can have it's own
alloc/dealloc range functions associated, and eventually generic
notifiers for hotswap.

I beleive we can build some kind of "device-tree" which would be made of
a virtual root, containing busses, containing resources trees. Looks a
bit like Open Firmware ;-)

Perso. e-mail: <>
Work e-mail: <>
BenH. Web : <>

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:53    [W:0.095 / U:9.456 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site