[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <alpine.LFD.2.00.0906112022000.31536@xanadu.home>
Date: Thu, 11 Jun 2009 20:38:43 -0400 (EDT)
From: Nicolas Pitre <nico@....org>
To: David Miller <davem@...emloft.net>
Cc: bhutchings@...arflare.com, mfuzzey@...il.com,
netdev@...r.kernel.org
Subject: Re: [RFC PATCH] Ethtool style in kernel network driver configuration.
On Thu, 11 Jun 2009, David Miller wrote:
> From: Nicolas Pitre <nico@....org>
> Date: Thu, 11 Jun 2009 16:24:05 -0400 (EDT)
>
> > Your shortsightedness and refusal for accommodation about needs
> > that aren't yours is representative of the main reason why there is
> > still a disconnect between mainline people and embedded people.
>
> Our main beef with the embedded folks is short-sightedness and a
> desire for quick solutions rather than clean ones with long term
> considerations in mind.
Let me quote Martin again:
| If your view prevails all I will have achieved is the replacement of
| my personel 2 line #ifdef hack by 500 lines of "generic" code that no
| one else will ever see. Of course in the grand scheme of things that's
| insignificant but then I hope people don't complain about embedded
| developpers not contributing enough. I did try, really.
Wasn't his patch looking like a clean solution with long term
considerations? If no then I don't think we have much else left to
discuss.
And no, as absurd and strange that might sound to you, maintaining extra
components to access the ethtool interface from user space (whether or
not it is for broken PHY or whatnot) in an embedded product is often not
worth the bother. Those systems are not workstations where all that you
have to do is fire an editor and type one line of command in a script
because the default environment makes everything already available.
Compare that to the quick solution that the one line hack represents.
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
Powered by blists - more mailing lists