Date: Sun, 01 Feb 2009 11:24:59 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: thompsa@freebsd.org Cc: freebsd-usb@freebsd.org Subject: Re: USB2 patches Message-ID: <20090201.112459.717301987.imp@bsdimp.com> In-Reply-To: <20090201175021.GA32503@citylink.fud.org.nz> References: <20090201030628.GE65558@elvis.mu.org> <200902011220.18745.hselasky@c2i.net> <20090201175021.GA32503@citylink.fud.org.nz>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20090201175021.GA32503@citylink.fud.org.nz>
Andrew Thompson <thompsa@freebsd.org> writes:
: > 3)
: > In general avoid more than a few synchronous USB transfer inside
: > attach/detach. Always defer! Else there are corner cases where the device can
: > hang waiting for the transfer timeout 1-5 seconds for every USB transfer, and
: > that is unacceptable.
:
: I disagree. It hugely simplifies drivers to know all the resources are
: allocated after attach, you dont need to check for null pointers
: throughout the code. If programming commands fail/timeout in the attach routine
: then the driver needs to check this and abort the attach. You will wait
: one or two timeouts max.
The only way that a 'deferred attach' makes sense is if the ifnet and
other external resources are setup as part of that deferred attach.
That way, you don't have the NULL pointer issue.
However, doing that introduces races with devd, which are a pita to
cope with... Even without deferring the setting up if ifnet, you have
races with devd if you defer things in attach that can be hard to cope
with in the code.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090201.112459.717301987.imp>