It is time to admit that removable devices exist

M. Warner Losh · *nix forums Guru Joined: 22 Mar 2002 Posts: 365

Please find enclosed the beginnings of a patch to make removable
devices better represented in the system. Right now all it adds is a
mechanism by which client drivers can ask if the device is still
really there or not.

The new bus_if method would be "child_present". The default,
implemented in the nexus, would return "yes." However, busses that
can have their devices removed, and can have knowledge of such an
event, are expected to override the bus_child_present method. In that
method, they are expected to make the determination, by direct
inspection of the hardware if possible, if the device is really there
or not.

child_present is expected to return 0 when the device is gone, and a
-1 when the device is present. This also happens to be binary
compatible with old releases since when you call a method that isn't
in a device's method table, it return ENXIO. This is non-zero and is
the most compatible thing you can return. Drivers that wish to cope
on their own with systems too old to have this call can check for 0 or
-1 directly and if not one of those two methods, they are free to
adopt their own ad-hoc methods for dealing. I expect there to be no
such drivers, but it never hurts to design for them. Most client
drivers will check for == 0 or != 0.

Why do we need this? Many device drivers do not properly deal with
device gone conditions. When the device disappears, they either loop
forever waiting for a bit to clear, or they have some kind of kludge
that prevents this from happening (0xff is magic, limits on the number
of loops, etc). It would be much cleaner if a device had a
bus-independent way to ask these questions.

I plan to implement this for both OLDCARD/NEWCARD soon, and also to
MFC it into -stable since it is useful and also backwards compatible.
It will likely be one of the last things that I do to OLDCARD.

Comments?

See http://www.freebsd.org/~imp/dev-gone.20020623 for a diff.

Warner

P.S. I just noticed that I don't have nexus driver changes for each
of our platforms. Of course I'll do that before I commit the code.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message

Doug Rabson · *nix forums addict Joined: 28 Mar 2002 Posts: 62

On Monday 24 June 2002 12:12 am, M. Warner Losh wrote:

Poul-Henning Kamp · *nix forums Guru Joined: 21 Mar 2002 Posts: 436

In message <20020623.171200.96231110.imp@village.org>, "M. Warner Losh" writes:

Dag-Erling Smorgrav · *nix forums Guru Wannabe Joined: 23 Mar 2002 Posts: 110

"M. Warner Losh" <imp@village.org> writes:

Poul-Henning Kamp · *nix forums Guru Joined: 21 Mar 2002 Posts: 436

In message <20020624163116.J95270-100000@sasami.jurai.net>, "Matthew N. Dodd" w
rites:

Poul-Henning Kamp · *nix forums Guru Joined: 21 Mar 2002 Posts: 436

In message <20020624.145012.32175932.imp@village.org>, "M. Warner Losh" writes:

Terry Lambert · *nix forums Guru Joined: 19 Mar 2002 Posts: 434

"Matthew N. Dodd" wrote:

Doug Rabson · *nix forums addict Joined: 28 Mar 2002 Posts: 62

On Monday 24 June 2002 9:46 pm, M. Warner Losh wrote:

Matthew N. Dodd · *nix forums beginner Joined: 24 Jun 2002 Posts: 9

On Sun, 23 Jun 2002, M. Warner Losh wrote:

M. Warner Losh · *nix forums Guru Joined: 22 Mar 2002 Posts: 365

In message: <20020624163116.J95270-100000@sasami.jurai.net>
"Matthew N. Dodd" <winter@jurai.net> writes:
: On Sun, 23 Jun 2002, M. Warner Losh wrote:
: > Please find enclosed the beginnings of a patch to make removable devices
: > better represented in the system. Right now all it adds is a mechanism
: > by which client drivers can ask if the device is still really there or
: > not.
:
: If a device driver is ever in a position to ask this question when a
: device is not actually present then we've got larger issues.

You need it in the detach method so that you don't flush things when
the hardware is gone. Also, there are times that the hardware can
just vanish out from under us, even while we're in some critical
section of code.

: I don't think this is the correct solution; adding function calls to all
: the interrupt handlers is broken, especially since PCMCIA doesn't really
: support hot removal of devices anyway. No other OS supports this correctly
: either.

We support it decently. People expect it to basically work.

USB and Firewire all properly support hotplug, but may also need a way
to know if their device has gone away while they weren't looking.
Hotswap PCI also needs this, but there there's hooks in the bridge
chipset that you have to hook into to properly quiess the device.
This is supposed to be a generic method.

: I suggest that you implement a PCMCIA/CARDBUS specific BUS_SETUP_INTR
: method that performs whatever check is needed before calling the driver
: interrupt handler.

We already do that. But lots of things can happen between when we
call the ISR and when the ISR finishes running. The call is indented
for ISRs that may wish to terminate always (which they should do
anyway).

: We should also implement 'ifconfig detach/unplumb/destroy' as an interface
: for forcing network devices (the most common hot removed device) to be
: detached. This will allow users to completely detach the device before
: they remove it.

That's not a viable option. We'd really need a 'devcontrol detach
sio4' to do things right.

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message

M. Warner Losh · *nix forums Guru Joined: 22 Mar 2002 Posts: 365

In message: <200206240958.48240.dfr@nlsystems.com>
Doug Rabson <dfr@nlsystems.com> writes:
: In your implementation of bus_generic_child_present, you pass the original
: device to the parent bus' child_present method. The idea of cascading the
: request is a good one (e.g. the phy of a cardbus ethernet card is clearly not
: present if the card itself isn't present). It might be better for the bus
: implementation though if you pass the bus rather than the original child
: device, e.g.:
:
: int
: +bus_generic_child_present(device_t bus, device_t child)
: +{
: + return (BUS_CHILD_PRESENT(device_get_parent(bus), bus));
: +}
:
: This would give the parent bus enough information to find the ivars etc. to
: make a decision about whether 'bus' is still present.

Maybe. However, I do not know if all busses can tell if an immediate
child can be detached always. I'm thinking specifically about USB and
its device tree. But USB could be written such that it can cope with
this.

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message

M. Warner Losh · *nix forums Guru Joined: 22 Mar 2002 Posts: 365

In message: <83073.1024951336@critter.freebsd.dk>
Poul-Henning Kamp <phk@critter.freebsd.dk> writes:
: When you eject a pccard, we may get in pccard-socket interrupt
: before it disappears but we may also not. Depending on the world+dog
: this interrupt me come before, during or after the relevant device
: driver enters its interrupt routine.

For ISA cards this is definitely true. Either the CSR happens first
or the card interrupt, depending on a lot of complex issues (including
the bridge generating interrupts in ways that are ill defined at
best). For PCI cards, where we have shared interrupts, we already
implement an interlock. We could implement one more layer of
indirection in the ISA case as well.

Still doesn't solve the detach issue (it is currently ambiguous: used
for both unload and for device has disappeared), which my proposal
solves nicely.

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message

Matthew N. Dodd · *nix forums beginner Joined: 24 Jun 2002 Posts: 9

On Mon, 24 Jun 2002, Poul-Henning Kamp wrote:

M. Warner Losh · *nix forums Guru Joined: 22 Mar 2002 Posts: 365

In message: <20020624164822.H95270-100000@sasami.jurai.net>
"Matthew N. Dodd" <winter@jurai.net> writes:
: I want to see the performance hit this causes quantified on lower end
: hardware before drivers are patched to support this API (which I concede
: may have some use outside PCMCIA devices.)

The cost on low end machines (where you have nexus -> isa -> device)
is going to be 3 indirect function calls per call for the non pccard
case, which is << 1us cycle time of the ISA bus. 3 indirect function
calls would be on the order of 25-100 cycles depending on the CPU.
For all but the slowest of hardware no one will notice this extra
processing. Even on a 33MHz 386 this would be only about 3us. I
doubt I could measure its effect on anything faster than a P90 or
P100.

Warner

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message

Google