Messages in this thread | | | Date | Sun, 18 Jul 1999 13:06:56 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: 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/
| |