netdev - Re: [RFC PATCH] Ethtool style in kernel network driver configuration.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-id: <alpine.LFD.2.00.0906111159080.31536@xanadu.home>
Date:	Thu, 11 Jun 2009 12:22:59 -0400 (EDT)
From:	Nicolas Pitre <nico@....org>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	mfuzzey@...il.com, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] Ethtool style in kernel network driver configuration.

On Thu, 11 Jun 2009, Ben Hutchings wrote:

> On Thu, 2009-06-11 at 08:47 +0200, Martin Fuzzey wrote:
> > Ben Hutchings wrote:
> > > Who needs this feature?  Why not use ethtool in an initramfs?
> > >
> > >   
> > > Forcing speed and duplex is occasionally needed to work around a link
> > > partner that doesn't implement autonegotiation correctly.  I don't see
> > > that it should ever be needed in platform configuration.  If the driver
> > > doesn't detect the MAC/PHY capabilities correctly then the driver should
> > > be fixed.  Overriding the settings once will not prevent an unsupported
> > > mode being selected later.
> > >
> > >   
> > To summarize the recent points I made in the smc91x: forcing speed thread :
> > 
> > 1) Setting up and maintaining an initramfs can increase the complexity
> > for embedded systems - it's another image file to build, distribute,
> > update to bootloader etc.
> 
> This doesn't seem like a huge burden if you're net-booting.  And if
> you're not net-booting, it's not critical that you override the link
> mode immediately; you can do it in the regular init scripts.

Sure... But for some embedded setup this is actually more trouble and 
hassle than having a non-intrusive kernel based facility that can set 
defaults for you.

The same way that the kernel currently has BOOTP and DHCP in the kernel.  
This is not necessarily the preferred way on a server or workstation, 
but damn useful on some embedded targets.  If DHCP and NFS root were 
removed from the kernel then of course using ethtool from some initramfs 
(along with dhclient and 'mount -t nfs') or the like would actually be 
the "right" way.  But CONFIG_IP_PNP_DHCP and CONFIG_ROOT_NFS are still 
in the kernel and unlikely to be removed soon.

> > I currently have this situation on one of my boards - 100Mbps doesn't
> > work due to electrical issues (bad routing).
> > This board is already in the wild - if it is fixed one day it will be a
> > new hardware revision and the code will have to cope with both.
> > Sure the "right" way is to fix the hardware but that's not always
> > economically or logistically possible.
> > I suspect such situations are not uncommon in the embedded world.
> 
> So, as I thought, you actually want to disable some modes completely.
> That is not what ethtool does.

No.  What is needed is to enforce a different _default_.  If someone 
manages to run ethtool after the system is booted and select the broken 
mode then that's just too bad.

Now the mainline people are (rightly) complaining that the 
embedded people don't participate enough and communicate their needs 
with the upstream kernel.  I think this is a good example from the 
embedded world providing a clean solution to a recurring issue which 
would return again to quick hacks if the mainline reception is 
"use a cramfs" again.

Nicolas
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html