Date: Mon, 24 Jun 2002 09:58:48 +0100 From: Doug Rabson <dfr@nlsystems.com> To: "M. Warner Losh" <imp@village.org>, arch@freebsd.org Subject: Re: It is time to admit that removable devices exist Message-ID: <200206240958.48240.dfr@nlsystems.com> In-Reply-To: <20020623.171200.96231110.imp@village.org> References: <20020623.171200.96231110.imp@village.org>
index | next in thread | previous in thread | raw e-mail
On Monday 24 June 2002 12:12 am, 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.
>
> 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?
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.
--
Doug Rabson Mail: dfr@nlsystems.com
Phone: +44 20 8348 6160
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206240958.48240.dfr>