[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, no? > 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. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part