Re: usbd does not use detach

In message: <20030815110016.00c00356.eaja_at_erols.com>
            Eric Jacobs <eaja_at_erols.com> writes:
: > In message: <20030814110113.4d238ddd.eaja_at_erols.com>
: >             Eric Jacobs <eaja_at_erols.com> writes:
: > : #    DETACH_FORCE: Clients using the device must be disconnected,
: > : #        typically by revoking open file descriptors. May not
: > : #        return EBUSY due to client activitiy, but may return
: > : #        that or other errors due to hardware problems or
: > : #        limitations.
: > : #
: > : #    DETACH_EJECTED: This call is made from a lower-level bus   
: > : #        driver when the device has been physically removed from
: > : #        the system. Like DETACH_FORCE, except that drivers can
: > : #        avoid attemping (and failing) to reset the hardware
: > : #        state. This request must succeed.
: > 
: > These two are redundant.  Devices can already ask the bridge driver if
: > the device is still present on the bus.  Smart drivers already do
: > this, but most of the drivers in the tree are dumb. 
: 
: How does one do this check? It is not obvious, which may explain why
: there are so many dumb drivers in this regard.

#
# Is the hardware described by _child still attached to the system?
#
# This method should return 0 if the device is not present.  It should
# return -1 if it is present.  Any errors in determining should be
# returned as a normal errno value.  Client drivers are to assume that
# the device is present, even if there is an error determining if it is
# there.  Busses are to try to avoid returning errors, but newcard will return
# an error if the device fails to implement this method.
#
METHOD int child_present {
	device_t	_dev;
	device_t	_child;
} DEFAULT bus_generic_child_present;

It is recently added.

: Another factor that aggravates this is that in some cases, the driver
: itself may not care about this check, but its clients will. For example,
: umass may well not need to do anything different depending on whether
: it was unloaded or its device was unplugged. But the layers below it,
: CAM, GEOM, and VFS, may still need that information. And they aren't
: going to know what the USB device is, much less how to query for its
: existence.

Well, somebody has to talk to hardware, and that somebody has to
cope.  And the problem is we can

: It seems to me that the solution for "dumb" drivers is to make it as
: easy for them to be smart, by doing as much as possible in the bus
: driver.

You aren't making things easier.  You have:

    switch (foo) {
    case DETACH_FORCE:
	 flush();
	 /* fall through */
    case DETACH_EJECT:
	 ...
    }

vs

    if (bus_child_present(dev))
	flush();
    ...

: > : In addition, the DETACH_FORCE and DETACH_EJECTED flags could
: > : be mapped to appropriate flag values for the other subsystems, such
: > : as MNT_FORCE and (a new) MNT_EJECTED flag for VFS.
: > 
: > The problem is that when you are detaching a device, it is gone when
: > you return from the detach routine. 
: 
: Right. I haven't looked at the code extensively, but I believe the GEOM
: "orphanage" concept handles this well. When the disk_destroy is called
: during the device detach, it means that GEOM will take over returning
: errors to clients who still may be trying to use the device, so that
: those requests won't get sent to the device, and the device would be
: safe to delete.

If this is true, then no driver work should be necessary at all for
disk devices.  However, the upper layers don't deal too well with
errors flushing.  And it does nothing for network drives that have
similar problems.

Warner