Roland McGrath <[EMAIL PROTECTED]> writes: > Anyway, this kind of question is for the device manager thingie to worry > about in the long run. Conceptually, the kernel should not be thinking > about peripheral hardware, and the device interfaces in oskit-mach are just > a makeshift solution putting in the kernel what only works in the kernel > right now, and a Hurdish user-level layer should cover the ugly innards.
Of course it belongs not in the kernel. The interesting problems happen regardless of which piece of software is doing the task, however. > > It also prevents the auto-detection of interrupt number, doesn't it? > > You'd have to turn off all other interrupts, and tickle the device. > > This is the business of the driver to figure out, in the oskit interfaces. > It doesn't really have to turn off all interrupts, it can just install its > special probe interrupt handler on all the canditate irqs that are not > already taken by other devices that won't share. Well, on a Vax at least, you could usually jumper any device to interrupt on any IRQ you liked. On a Microvax typical devices had a smaller but still fairly configurable range. On a PC, it's usually much more limited, but sharing is *very* important. So how do you handle that? It seems like you still will have to turn off any device that might conflict. It won't be the whole bus like a Vax, but it will still be something. > In practice, the probe always happens very early. The first time a > device_open is done for the root disk, that probes the root bus and that > recurses on the busses for controllers it finds and so forth. Hrm. Sure, that's fine for the main hard disk. But what about some occasionally-used peripheral? The first time I open the CD writer which lives on its own IDE controller: I don't want that to cause the whole system to pause for a second. And worse yet, I fear, is when you try to open a device that isn't there, but you don't get I/O errors when you poke at at: then you have to time out waiting for the interrupt. _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
