> 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.
>
This is completely orthogonal to the `Two Trees' (cf. Tolkien ;->)
issue!
We can (and probably should) make all drivers allocate their resources at
init time. We also should make them receive data from the bus scan so
they won't do this allocation themselves but instead receive it from
outside (if possible). The other tree is neccessary only so that the scan
itself can be done in a sane fashion.
One sane (and backward-compatible) interface for this may be quite similar
to David's current PCMCIA support. Drivers which know about the new
system don't initialize any hardware state in their init function, but
only global driver data; they then call register_driver(). The bus
drivers then allocate the (normal) resource nodes for the device and
invoke the thus-registered hardware initialization function (once per
physical device that should be handled by the driver). At the end of all
this, the resource tree is fully populated.
Drivers which aren't updated will still try to use the resource manager as
a locking facility, but they'll work; they just won't properly support PnP
or hotplug.
And, since we _anyway_ need such a `register_driver' (or equivalent) for
supporting hotplug _at_all_, I believe it's a definite win.
> 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..
>
It can be both at the same time.
-az
------------------------+----------------------------------------------------
. __ | Phone: +972 3 5340753 (home), +972 3 9685882 (work)
_| / | email: alonz@usa.net
/ | /_ Alon Ziv | smail: 33 Ha-Rama St., Ganey Tiqwah 55900, Israel
------------------------+----------------------------------------------------
<<<(((this place reserved for that ultra-wise oneliner I haven't found.)))>>>
-
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/