> Steven Stallion wrote: >>> 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. >> > > Actually, the current approach, where MII bits are expressed directly, > is pretty simple for most devices. The reason for this is that most > devices (at least modern ones) actually expose MII registers directly to > the driver, and so there is a one-to-one correspondence between what > gets requested and what gets set. Trying to abstract this further would > actually make *more* work for such drivers. > > Now there are *some* devices (some dnet variants using SYM are good > examples... mxfe has the same problem) where the MII registers are *not* > exposed, but abstracted somehow. This is mostly older devices, designed > before 802.3u was ratified, and they have more work to do. I'd rather > leave the work for those devices, and keep the more modern ones simple.
Fair enough. ;) I think the real thrust of what I was suggesting was to provide a utility function to return a list of configured modes to help during negotiation. Steve _______________________________________________ networking-discuss mailing list [email protected]
