lkml.org 
[lkml]   [1999]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: New kernel/resource.c
Date
From
>But conceptually the notion of "this area contains removable devices" _is_
>obviously a hierarchy issue. No question of that. That's why I wanted to
>make the resource control hierarchical in the first place.
>
>I'm just saying that that issue actually has very little to do with the
>bus. There might be a completely flat bus that has removable devices. Or
>there may be a complex hierarchical bus that has partly removable devices.
>The resource hierarchy should be concerned not with the physical layout of
>the bus, but with the logical issue of "removability" for example.

Hmmm... at least in the area of older ISA/PCMCIA systems, a
PCMCIA cad, say a modem, could appear anywhere (that the card permits)
in the ISA I/O space. In fact a single card could contain several
different ranges of I/O ports, as well as memory address windows, DMA
resources, IRQs. In this sense, the entire ISA bus is a "removable"
area when PCMCIA is connected.

Part of the issue, I think, is that bundle of resources of
differing types needs to be considered as a unit for certain types of
operations beyond simple conflict detection. Consider some of the
cruft in ISA configuration: a serial card might support COM1: I/O
ports with a particular IRQ, and COM2: I/O ports with another IRQ, and
not allow mix-and-match configuration. (Yuk, what an awful design!)

Consider a PCMCIA combo card, with a SCSI controller and an
Ethernet controller (assuming such a combo were marketed), and a mix
of disk, CDROM, and tape drives connected to the SCSI bus. When you
eject the card, some entity needs to notify the Ethernet driver and
the SCSI driver of the ejection event. The most reasonable basis to
do this, I think, is some representation of the fact that they share
the same physical slot. There's probably no relationship between the
I/O port addresses used by these devices; they'll most like occupy
disjoint ranges of IO port space, with other devices' ports scattered
inbetween.

Continuing the example, the SCSI driver ought to be able to
notify the disk, CDROM, and tape drivers of the disconnection event.
It could do this on the basis of its own data structures. However,
and this is speculation on my part (and other parties to this
conversation might have more pertinent experience), it might make a
lot of sense, from a system configuration and maintenance point of
view, to keep a uniform kernel representation of the physical bus
connections in the system.

I've read only a little about USB; doesn't it allow for
multilevel heirarchical bus segments?

In summary, I see three distinct problems with different
solutions:

1) a linear resource space allocation problem, that can be
addressed by the proposed range-based resource allocator.
(I/O ports, mapped I/O, IRQs, SCSI bus addresses, etc.?)

2) a disconnection event problem, that can be addressed by a
(uniform?) representation of the physical connections between
(some) parts of the system. Example: PCMCIA, USB?

3) a startup/connection event problem, that requires some
yucky conflict resolution, a knowledge base of deceptive
and defective components, a persistent representation of
the preferred and reserved configuration elements for
this particular system... it ought to be in user space,
but some of it has to be in the kernel for bootup on some
systems. (PCMCIA, ISA PnP?)

Craig Milo Rogers


-
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.128 / U:0.176 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site