blocking in dev->open (was: [ipw3945-devel] chaning mode only when interface down?)

[picking up on this old mail again, somehow remembered it]

On Fri, 2007-08-03 at 07:20 -0400, Dan Williams wrote:

> > Not sure I understand? Drivers can fully well block the userspace task
> > that is doing the IFF_UP until they're read? bcm43xx does that.
> Well, I'd rather that the driver actually not block (NM uses netlink
> here anyway, not an ioctl) but there be some flag to look for when the
> device actually is up.  That implies that the device not set IFF_UP on
> itself until it actually _is_ up.

Well, since IFF_UP is set by the networking core after ->open() returns
there isn't much a device can do about when to set it. However, if it
blocks in ->open() until it is ready, the right behaviour falls out
automatically, IFF_UP is only set when it's ready. I think blocking
there is definitely the right behaviour. NM simply needs to wait for the
netlink reply a little longer then.

How do you think not blocking should work? The device can't influence
IFF_UP, when its open() callback returns IFF_UP is set and it is assumed
that the device is operating. It's designed to be blocking. And besides,
if you don't like that, you can spawn a thread to do the flag setting,

> I think the biggest offender for
> up-misbehavior used to be prism54 FullMAC, because it had to reload the
> firmware for almost every operation, and that could take over a second
> or two to load & reboot the firmware.  There wasn't a good way of
> telling when that was done and the firmware was ready for business.  So
> you end up having sleep(2) calls littering the code to deal with these
> sorts of little things.

Well, I think it should just block for all that and you should simply do
it out of the main thread if it's such a big deal.


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]