> I've seen a few others that are weird though-- collision recovery > algorithm tuning (enable proprietary back off algorithms), wake-on-lan > tweaks, inter-packet-gap tuning, tweaks to support extended cabling, > signal enhancement tweaks, proprietary (Bay networks) PHY based flow > control schemes. Any of those would be private tunables. Many of them > shouldn't be adjusted by the vast majority of sites. I'm not sure its > fair to "hide" them, though. (Which is what lack of an enumeration API > does.)
They are not really hidden, they are just not discoverable directly through dladm. That is, the driver that has the proprietary PHY-based flow control scheme can document that in its manpage, along with what the various settings mean. Again, I believe this is the right balance. I have not yet seen a convincing case made for a driver-private tunable the admin needs to muck with where they can't be bothered to read the driver manpage to learn about it first. (As an aside, our network driver manpages really need some work -- many of them still describe common stuff that is automatically handled by GLDv3, and suggest direct programmatic access via DLPI primitives on their /dev node; all of this text needs to be updated and much of it needs to be changed to reference a common manpage that describes interacting with /dev/net nodes. This has been on my TODO list forever but I never seem to get to it.) -- meem _______________________________________________ networking-discuss mailing list [email protected]
