Sebastien Roy wrote: > Crossbow team, > > If you read the Public Comments in 6871916, there is an open question > regarding why mac_set_mtu() calls mac_mark_exclusive(). I personally > don't see why the i_mac_perim_enter() on its own doesn't implement the > exclusivity semantics required by the function (it's essentially just a > kernel wrapper around setting the "mtu" link property). Can anyone shed > some light on this? > The perimeter does ensure that only 1 thread can do mac_set_mtu() at a time on the given mac. But I am not sure why mac_set_mtu() wants to call mac_mark_exclusive(). Is it that not all drivers implement the mac_maxsdu_update() and so we can't change the mtu except if we are the only mac client ?
Thirumalai > Aside from panicing the system due to 6871916, this also has the > negative side-effect of preventing other threads from issuing mac_open() > while mac_set_mtu() is in progress (other threads will get back EBUSY). > It doesn't seem right to me that opening /dev/net/foo0 (for example) > would return EBUSY while setting the "mtu" link property, but not any > other link property, or issuing any other "administrative" operation > that requires the perimeter (such as adding multicast addresses, etc.). > > -Seb > > > _______________________________________________ > crossbow-discuss mailing list > crossbow-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/crossbow-discuss >
