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

>> I've still got a laptop on my desk that doesn't have a PCI bus.
...
>If it's the name you object to, then just don't call it PCI. Call it
>"peanuts".
...
>So instead of using confusing names like "peanut" or "pci_or_isa_or_
>pcmcia_or_who_the_hell_cares_what_electrical_bus_is_outside_the_cpu_
>as_we_cannot_see_it_anyway" , I'm just calling it "PCI". Fair enough? It's
>99% of the interesting market these days.

Unless you are explicitly modeling the other busses as PCI
variants (sorta like the IDE-to-SCSI emulation option), calling the
general I/O resources "PCI" is misleading, confusing, and perhaps dumb.

It's misleading because it uses the wrong name for a concept.
It's confusing, because newcomers to the kernel (and even more
experienced hands) will misunderstand the semantics associated with
"PCI" resources. Finally, it's perhaps dumb because it implies that
PCI is the final bus, and a massive rename will be needed with we
stransition to the next system bus (on the other hand, I appreciate
the argument that the forced rename makes for a less buggy
transition, so maybe it's not dumb).

Wouldn't it be clearer to call the two I/O resource spaces,
say, ioport_resources and iomap_resources (ioremap_resources,
iomem_resources, ...)? In my abjectly humble (hah!) opinion, this
would be the Right Thing to Do.

>In particular, you don't have two resource trees for one and the same
>resource. Also, you don't try to have a resource tree based on any
>electrical hierarchy (ie you do NOT try to follow PCI bridges or whatever
>that are largely invisible from a software standpoint).
...
>What the peanuts actually are electrically you don't care about, because
>you really cannot tell a difference.

I'm surprised by these claims; I'll attempt to disprove them.
When dealing with hot-swap implementations (PCMCIA, SCSI, PCI, etc.),
the electrical heirarchy tells you which physically related devices
will be removed when a disconnection event is noted; for example, a
PCMCIA card eject event for a multifunction PCMCIA card. Based on
this information, you know what device drivers should perform an
emergency shutdown, which is (I assert) a desirable thing to do.
Therefore, you care about the electrical heirarchy. QED.

Should the electrical heirarchy be represented using the same
generic resource management tools as the I/O port allocations?
Perhaps, if it fits the problem; personally, I think that a simple
tree structure would be more appropriate here. Should the kernel
maintain it, or should it be in user space? Because of the
interactions with the device drivers, I'd prefer a kernel solution, I
think.

I'd also like to address the problem of reserving resources
for devices that don't exist (but might have existed in the past, or
might exist in the future) (correct me if I'm wrong!). The general
case of this problem is fairly difficult, and I can easily imagine
that the conflicting constraints of different devices would not fit
into a single resource allocation tree. Should these resource
conflicts be managed in the kernel? Maybe; it might simplify some
bootstrap issues, and some PNP configurations might require boot time
kernel support.

FInally, on the issue of evolutionary vs. revolutionary
changes in the Linux kernel. I appreciate the view of those who
write, maintain, or use Linux kernel modules outside the main kernel
tree; evolution if far better for them. However, the revolutionary
changes that involve calling new subroutines (as opposed to
calculating new expressions) seem to have been cleaner in the long run.

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