Date: Fri, 20 Jan 2017 13:36:44 -0500 (EST) From: Garrett Wollman <wollman@hergotha.csail.mit.edu> To: gallatin@netflix.com Cc: freebsd-net@freebsd.org Subject: Re: RFC: ethctl Message-ID: <201701201836.v0KIailL014327@hergotha.csail.mit.edu> In-Reply-To: <c21ec3d9-a539-6c7d-4bd3-6413e7149b2b@netflix.com> References: <c21ec3d9-a539-6c7d-4bd3-6413e7149b2b@netflix.com> <CAK7dMtCSRu6L67A46FU0eYqJ9=zGdyJPvBXLkL7gKbh=SbZ6cQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <c21ec3d9-a539-6c7d-4bd3-6413e7149b2b@netflix.com> you write: >Eg, I don't see why we need another tool for some of this missing >"ethtool" functionality; it seems like most of it would naturally fit >into ifconfig. >From the end-user perspective, I agree with Drew. Most of this stuff should just be part of ifconfig. >As to other features, like writing firmware images and/or reading >dumping eeprom -- these were never a natural fit for us. And I can't say that I've ever wanted to do this. Most of the machines we buy these days are Dells, and Dell USC takes care of all the firmware updates. Having a not-really-generic firmware programming interface that only works for network interfaces seems like very limited value. I wouldn't object to it, but I doubt I'd ever use it, and I expect most vendors will want to keep tighter control over applying firmware updates. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201701201836.v0KIailL014327>