> Steven Stallion writes: >> > Right, see >> > http://gdamore.blogspot.com/2008/08/why-you-dont-want-to-force-link-modes.html >> > for my most recent rant on this particular topic. >> >> I'm suddenly reminded of hours spent in the lab years ago trying to get >> a >> PIX and ProCurve to play nice... >> >> It really sounds like this behavior could be abstracted out and placed >> into a capability. Essentially all you would really need is a couple of >> utility functions to simplify exposing a set of adv_ props, and to read >> (in order of 802.3 precedence) a set of config modes. > > I'm not sure what "capability" means here, but I do agree with you > that having an analysis tool that reads the various stable > configuration and status bits and produces a human-ready report (along > with a diagnosis) would be extremely useful -- and not terribly hard > to write. > > This is something that's been discussed more than once ...
A Nemo/GLDv3 capability (i.e. MAC_CAPAB_ADV or somesuch). Essentially a driver which wants to use this cap would register a couple of callbacks so Nemo could request what the device will advertise and provide a utility function or two for getting any en_ modes which have been set by the user. As far as stable status bits, this pretty well limits the cap to devices which support MII/GMII/XGMII xcvrs. Right now, I am also working on adding 802.3 MII/GMII support as a capability to Nemo; this just seemed to be another cap that could be added (pretty simply actually) which would life a little easier for driver dev's. _______________________________________________ networking-discuss mailing list [email protected]
