> I'm not familiar with the IRIX model, but thought that the Solaris model
> handled most of the stuff in a reasonable way. In the past, my observation
> has been all things IRIX tend to be a little clunky.
>
> Is the IRIX model DDI/DKI?
I'm not sure what you would call it. :) And yes, it is quite clunky
but I'm only referring to the attach/detach/load/unload set of calls.
This is essentially the same as the way Solaris handles it.
- Request device/vendor IDs (load)
- Get called when a device is needed (attach)
- Get called when a device is removed or unneeded (detach)
- Remove the driver (unload)
The former could be done by a probe for what device/vendor IDs are present.
The latter should only be done upon user request.
>
> The Solaris model is nice in that it also documents the race conditions that
> you can get into between open, attach, and unload. They currently have
> PCMCIA support. They have configuration files for each device.
That's my concern with the instance number. If a driver is not aware
of possible races, it could assign two devices to the same
minor number (which would be a very bad thing).
>
> I wouldn't want to copy all facets of the implementation. It is very
> annoying that you have no way of controlling the instance number assigned to
> a device. Since you usually use the instance number as your minor number,
> this can cause some headaches.
Again, I don't care how it's done as long as there is no race for
the instance number. (A set of macros with a spinlock would accomplish
something similar, but allowing the driver to choose what the
numbers are)
-- Eric Lowe FibreChannel Software Engineer, Systran Corporation elowe@systran.com"You can't spell failure without U-R-A." -Dispair.com
- 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/