Re: [BKPATCH] bus notifiers for the generic device model

[Patrick Mochel]

> > I don't recall why the change was never done. Perhaps because of other 
> > distractions, or it seemed like it would be too much of a PITA to convert 
> > drivers to a two-step init sequence (though I think it could be done in a 
> > compatible manner).
> 
> 
> Possibly because of the "do it in open(2)" rule?
> 
> Ignoring the device model entirely, if a driver does a lot of 
> talking-to-the-hardware in its probe phase, I consider it buggy, in 2.4 
> or 2.5.
> 
> The network driver and chardev ones typically follow this rule quite 
> well... probe is simple, just registering interfaces with the kernel. 
> dev->open is where the driver should (and usually does) power-up the 
> hardware, [re-]initialize it, etc.
> 
> So each time you come upon a driver that wants dev->driver->start(), 
> look closely at the code and wonder why it can't perform the 
> dev->driver->start() code in its interface's dev->open member.

Oh, right. Sorry, I should have said 'init()' or 'setup()' rather than 
'start()'. 

In many drivers there are two discrete operations that happen in the 
probe() method: verifying the device can be claimed, and registering the 
interfaces. By breaking it into two calls, you can conceptually separate 
the actions. It would also give the bus a chance to intercept the call and 
perform whatever housekeeping it needed to do at that point, giving James 
what he wanted.

However, I don't see a great benefit of doing this, besides making it 
_blatantly_ obvious what each call is supposed to do. The driver can call 
the bus to perform housekeeping duties during the setup (probe()) period, 
and everything should be happy.

	-pat