On Thu, Dec 21, 2000 at 01:26:02PM +0100, Lennart Augustsson wrote:

 > Well, take USB devices as an example.  The match is easy, but while
 > attaching you often need to frob the device a little (frobbing during match
 > would be a BAD idea).  Well, doing I/O to a USB device can fail at
 > any time.  If it fails, I'd like to indicate this.

You CAN indicate this.  You print "foo0: blah blah failed" and you don't
actually finish the attach, which makes it impossible to use the crippled
device.

 > Another example, you might need to allocate memory in the attach.
 > Checking that there is memory while doing the match doesn't guarantee
 > anything since another thread might have taken it.  (I guess this is a
 > point where a waiting call might be acceptable, but you don't want to
 > hang the attach thread really.)

...you print "foo0: unable to allocate memory" and you don't actually
finish the attach, which makes it impossible to use the crippled device.

 > There are some situations where the match simply cannot know that
 > the attach will work for sure.

Granted.  But just because the attach won't work, does not mean that the
device is not there!  The kernel has found a device, matched up a driver
to it, and attempted to attach a driver instance to the device... that
failed, fine.  But telling the kernel "oh, pretend that the device isn't
there now" doesn't exactly seem like the right solution to me.  Obviously,
you want to mark the hardware resources (e.g. PCI space, etc.) that the
device occupies as "in use".  And when you unplug a hot-swappable device,
you still get an event, even though the driver didn't finish doing its
job of attaching itself.

 > I wouldn't suggest backing out and try a lower match.  If the attach fails
 > it means that something is seriously wrong and we should just tell the
 > user and mark the device and unusable.

You can already mark the device as unusable!  Take the case of an Ethernet
device, for example.  If the attach fails, don't call if_attach().  That
will nicely prevent the device from being used.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>