On Thu, 10 Mar 2005, Patrick Mochel wrote: > Because it makes it explicit what the actions are at each step, > distinguishing the operations on the physical bus-based device from the > logical class-based device. > > probe/remove and suspend/resume are actions for the physical device. They > are likely to touch the bus-specific hardware of the device (e.g. control > registers). > > start/stop and open/close are operations for the logical device. For each > logical device, and recall that there can be multiple and even arbitrary > numbers of logical devices per physical device. They do not control the > physical state of the device, and while they may touch hardware registers, > those are going to be MMIO-like registers, rather than e.g. PCI or USB > specific registers. > > The distinction makes sense, mainly because it's already present, though > not explicitly codified. Take a look at the eepro100, e100 or e1000 > drivers. There is a point during ->probe() (as with many net drivers, I > assume) where the function stops setting up the device and starts enabling > features. That's where you would draw the line from ->probe() to > ->start(). > > Making the separation has a few benefits (note none of which are critical, > or else we would have done it already). Devices that have a (current, > potential) arbitrary set of logical devices can have them all created and > ->start()'d in parallel. (Video devices or complex networking devices are > likely to have an arbitrary number.) We can completely remove a > logical-device subsystem module, without having to remove every single > driver (e.g. the DRM, fbdev, or future video interfaces) and reinsert > them. And, it forces a divorce of the physical from the logical in the > drivers, making them more compartmentalized and hopefully easier to deal > with. > > Does that help? Yes, thank you. Having worked mostly with devices that don't offer much in the way of feature sets, I wasn't aware of these issues. Alan Stern
