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]

Date:	Thu, 11 Jun 2009 20:31:59 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Nicolas Pitre <nico@....org>
Cc:	mfuzzey@...il.com, netdev@...r.kernel.org
Subject: Re: [RFC PATCH] Ethtool style in kernel network driver
	configuration.

On Thu, 2009-06-11 at 15:08 -0400, Nicolas Pitre wrote:
[...]
> > Please note, I'm talking about an init script -
> > which you surely must have - not an initramfs, which I recognise is
> > optional and unnecessary for most embedded systems.
> 
> An init script is already a luxury for some systems.

And so is an Ethernet port.  Instead of talking about hypotheticals, why
not talk about the system you need this workaround for?

> It means a 
> script, which implies a shell, and of course the tool binaries (ethtool 
> in this case) to be called by your shell.  Not only those do bloat your 
> system (the shell + tool + script occupies way more space than the 
> proposed module)

Well, if you're replacing init - which is generally a really bad idea,
by the way - you can build the ethtool API calls in there along with all
your other application-specific stuff.  The ethtool API isn't terribly
complex.

> and then you do have to maintain those components as 
> well, but it also has impact on boot time.  Remember that we're not 
> talking about systems bragging about their boot time being under 20 
> seconds here, but systems that need to be operational in only a couple 
> miliseconds.

If you want to boot that quickly you definitely don't want to have to
wait for PHY operations.

> > I was thinking that you could add it to the platform data for such
> > devices, not that you would put board-specific quirks in the drivers.
> 
> And what if the majority of users for a driver simply don't need such a 
> thing?  And how do you do that if the driver you need is for a PCI 
> device?

Any device can have platform data; it's part of struct device.

> And why would driver specific kirks be better than a generic 
> module that can handle those params in a uniform way across all drivers?  
> Especially if you can ignore said module if you don't need/want to use 
> it?

Because its raison d'etre is apparently to disable the broken link
modes, and it doesn't do that properly.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
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