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

From: Ben Hutchings <[email-masked]>
Date: Thu, 11 Jun 2009 20:31:59 +0100

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.