lkml.org 
[lkml]   [1999]   [Jul]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: New kernel/resource.c
On Fri, 16 Jul 1999, Linus Torvalds wrote:

[...]
>
> The code in kernel/resource.c indeed _is_ meant to be used for anything.
>
[...]
>
> The argument actually started from a non-naming issue: the issue of using
> two separate resource trees to describe the same resources (so with two
> different PCI resources - memory-mapped and IO ports - you would actually
> have _four_ different resource trees: memory would have two, and IO ports
> would have another two resource trees).
>
[...]
>
> The reason for two resource trees for the same resource would be that one
> would contain some kind of "static rules" resource description, and the
> other one would contain the "current setup" resource description.
> Everybody basically agrees that you _do_ need to have both.
>
I believe here's where you got David's idea wrong.

In my understanding of David's idea (I hope he'll correct me if I'm
wrong...), what he suggested was just that we use the same resource
manager internally by the various PnP support subsystems to maintain the
hardware hierarchies. The hardware hierarchies will be preallocated (if
needed); they may be used to route hotplug events, or to configure drivers
(if the drivers support this kind of `external cueing', which they _will_
need to do for proper PnP).

So, the two trees suggested by David _are_ for different concepts: one
describes the logical resources in the system (and it's exactly the one we
have now); the other tree is something that's actually internal[*] to the
PnP code, and describes what it knows about the hardware (and it doesn't
exist _at_all_ in the current kernel).

So, is this acceptable now?

-az

[*] There actually may be a place where these internal resources will be
`leaked' outside, and that is when the PnP code needs to configure a
driver to some specific hardware it knows about (and we don't want the
driver itself to probe when the PnP code already knows its resources).
Although, come to think of it, maybe it's better to use something
different than these resource records to pass this information; as
David has mentioned, the driver may see multiple hardware resources as
one logical resource, and it's probably not the driver's rightful task
to assemble this logical resource from all of the physical ones it's
given...

------------------------+----------------------------------------------------
. __ | 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/

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