On (10/15/07 09:23), Garrett D'Amore wrote: >>> * add new "enable_xxx" (where xxx is 100fdx, 100hdx, etc.) properties >>> which becomes the administrative *control* point. >>> * and new properties, "cap_link_pm", "enable_link_pm", and >>> "link_pm_state", which are boolean values indicate the ability to do this >>> kind of link power management, whether it is turned on, and the current >>> state (link speed is reduced for power management or not). >>> >> >> is the ideal solution. >> > > I'm glad you think so! Any chance of getting this into the commitment > materials before Wednesday? (I apologize for not getting you this feedback > earlier, but I really only considered the impact on Brussels last night.)
I can't update the materials any more, but we can certainly add it to the AI's and make sure it gets addressed prior to cteam reviews. > I will confess, the more and more I think about it, the more and more I > start to believe that the ndd interfaces really should just be removed > outright. Unfortunately, yanking out ndd(1m) has to be done gradually, so the project team has adopted the solution below 1. as part of PSARC 2007/429, attempts to use ndd calls (either via /sbin/ndd, or by issuing the ND_SET/ND_GET ioctls directly) will succeed, but, for each converted driver, a warning message (sample shown below) will be issued: <timestamp> <hostname> bge: WARNING: The ndd commands are obsolete and may be removed in a future release of Solaris. Use dladm(1M) to manipulate the adv_autoneg_cap property 2. new drivers must not provide any ND_SET/ND_GET ioctl handling code of any sort. 3. the ndd compat component of Brussels will clean up the existing ndd code in drivers so that legacy support for the ndd ioctls will be deflected from the GLDv3 (dld/mac) layers. (for the curious, there's a work-in-progress code review at http://mail.opensolaris.org/pipermail/brussels-dev/2007-October/000488.html) > Right now the problem is that a few internal consumers of ndd exist. I > don't have a problem with breaking most of them (NICDRV is one such, SunVTS > is another), but I'd prefer not to break SunVTS. Maybe this means that > SunVTS needs to change. We are looking into SunVTS, and what changes would be involved. > What does the project team, and what does ARC think, about just yanking > these interfaces in Nevada, and marking them Obsolete in S10u5? > > Are we willing to deal with the fallout from the breakage from the places > that have done their own thing? IMO, this breakage is not very different > from the precedent set by SMF... when SMF came out, a bunch of > administrative practice surrounding init.d scripts and inetd.conf was > "busted". I think folks adapted rather gracefully to it. Furthermore, I > think the scope of breakage that would be created by removing the NDD > command and underlying ioctls (at least for NIC drivers) is not too bad. > Indeed, not every NIC driver even supports these ioctls. While this is all true, I disagree that we should break these interfaces in S10u5 - we can mark them Obsolete and provide legacy support for the ndd paths. --Sowmini
