lkml.org 
[lkml]   [1999]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New kernel/resource.c


On Sun, 18 Jul 1999, David Hinds wrote:
>
> Linus thinks one resource tree is the only way to go because we are
> conceptually describing a single resource. I think two trees are
> better, because the only parts of the kernel that care about the
> static info are hot plug bus drivers, and because putting this info in
> the same tree with the current info will be tricky.

Note that =I= would actually prefer for as much information to be in the
device resource tree as at all possible.

I actually don't like the fact that right now devices tend to populate the
tree only when opened - it makes it hard to write a nice utility that
shows all IO ports in the system.

So what I want to move towards is that the bus scan will populate the full
IO (ioport and memory) resource tree, and that drivers themselves would no
longer use the resource tree as a "locking facility", which is what a lot
of drivers do now.

Yes, some buses don't allow for scanning. ISA (without PnP) is the obvious
one. For those we don't have any other option than to have the drivers try
to probe and insert their information as they find it. But I'll be very
happy if that ends up being the rare case rather than the way it is now,
where basically _all_ drivers end up trying to populate the resource tree
even if we often have better information from the IO scan.

I actually think that maybe our largest difference is that you want to try
to make your scheme work in the current setup, while what I really want is
a _future_ scheme that just does things right - where the resource tree is
always up-to-date _regardless_ of the drivers connected. That's what I'd
like to aim for..

Linus


-
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/

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