On Wed, 9 May 2007, Cornelia Huck wrote:
On Wed, 9 May 2007 01:33:14 -0700 (PDT),
[email protected] wrote:
1. why should different, unrelated busses need to wait for each other?
picking two, why can't you have SCSI and USB going through their timeouts
at the same time?
If they don't have dependencies on each other, yes. Some busses should
be finished before probing for others start (e.g. low-level busses).
I think we are agreeing on this, I was responding to your question of if
we could get away to limiting things to one bus at a time.
2. I'm not sure that you can always do the device enumeration before you
do the slow probing, there's another message in this thread that talks
about a USB device where you need to load firmware to it before you can
find out what is really there. in a case like this devices would either
show up in a random order during step #2, or they should not be added to
the system until step #3, which makes step #3 more then just waiting for
the async portions to finish.
I'm not sure whether that is not really a question of "one depends upon
the other". If the low level bus knows where to point its probe at, the
higher level should be able to look at sane devices after the firmware
has been loaded (or am I misunderstanding the situation here?)
makeing up an example
today the process would be
call driver X to initialize it's devices.
driver X follows these steps
1. see if a compatible chipset/device appears to be available
2. initialize the chipset/device (loading firmware)
3. query the now partially initialized chipset/device to see what specific
options are enabled in the hardware
4. for each 'thing' that's enabled in hardware, initialize and register
it.
step 2 can take a long time and so you want it to be async so that it's
timeouts can be running in parallel (for that matter step 1 may have some
timeouts as well)
however, you can't tell what devices to register until after step 3
so in at least some cases, it seems as if the registratin of devices needs
to be after the async section.
Linus made a good case fo an example (hard drives) where the registration
can happen first and fast, but the async section (spinning up) takes a
while and could come second.
to acommodate both of these device models it seems to me that you can't
defice either
async followed by sync
or
sync followed by async
but instead need to support the combined
sync followed by async followed by sync.
now, it's very possible that I'm mistaken and one of the two-part models
can be used for everything, if so then it's definantly simpler to do so.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
