Darren J Moffat wrote:
> James Carlson wrote:
>> Darren J Moffat writes:
>>> We can argue this indefinitely but regardless of what some PSARC
>>> members think admins, developers on Solaris and other platforms act
>>> differently.
>>
>> Regardless of how they act, we don't apply any engineering towards
>> making their actions supportable.
>
> and there in lies the problem, we are not meeting customer needs here.
> Customers and partners really just don't care about that, we know they
> build stuff on top of syslog. They expect to build stuff ontop of
> syslog on all platforms not just Solaris. IMO we need to take the
> fingers out of our ears and stop just saying "la la la la la la"
> everything this comes up and ignoring what the customers use and we
> know they use.
>
> What I'm saying for *this* case is that a reduction in the information
> presented is a problem and for me it means that this case doesn't meet
> its goals.
>
But for existing customers, the existing information was not provided in
anything remotely resembling a consistent manner. Each driver did its
own thing. For a customer/application to have depended on this kind of
information would have been utterly insane, if they wanted the
application to work with different NICs, etc.
I have investigated, and I can provide this information without too much
pain, but I still disagree with it in principle.
The reason for this is that today the mac layer knows nothing about many
of these link details, and it really doesn't need to. Furthermore,
there are reasonable situations where the link speed can change without
generating any kind of notification. (The typical example being link
speed adjustments that are done on 802.11 links.)
If folks really really want this information for 802.3 links, we can do
it. I just don't think its reasonable.
I also think, most tools just want an "up" or "down" notification (not
details on speed or duplex), so very few are likely to be negatively
impacted (other than they will have to adjust their scripts/tools to
recognize the new "up" and "down" messages, but then one format will
cover _all_ GLDv3 NIC drivers.
Note that some NIC drivers don't even bother to log this at all. For
example, 802.11 drivers do no link state logging whatsoever. My case
would add this for those drivers.
-- Garrett
