netdev - Re: [patch 12/12] Configure out ethtool support

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: <1217501371.3454.148.camel@pmac.infradead.org>
Date:	Thu, 31 Jul 2008 11:49:31 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	David Miller <davem@...emloft.net>
Cc:	akpm@...ux-foundation.org, torvalds@...ux-foundation.org,
	thomas.petazzoni@...e-electrons.com, shemminger@...tta.com,
	jeff@...zik.org, netdev@...r.kernel.org, mpm@...enic.com
Subject: Re: [patch 12/12] Configure out ethtool support

On Thu, 2008-07-31 at 03:43 -0700, David Miller wrote:
> From: David Woodhouse <dwmw2@...radead.org>
> Date: Thu, 31 Jul 2008 11:39:36 +0100
> 
> > We need to be moving towards a situation where people don't _need_ to
> > patch the hell out of their kernels to make Linux viable for embedded
> > devices. I'm not prepared just assume that 'they will always do so', and
> > I'm disappointed to hear Andrew say such a thing. 
> 
> It's simple economics, really.
> 
> Until they see value in upstream submission, it's always going
> to be %100 invested in getting the current product out the door
> or the current fire put out.

They are starting to see value in upstream submission. Even when I was
working for my previous employer, when we first started doing embedded
Linux contracts, it was sometimes a fight to be allowed the time to
merge stuff upstream.

But they had learned for themselves, over time, that it actually helps
them in the long run if they do that. Because when they come to do a
product update, or a new product similar to and old one, it means they
don't have to start again from scratch.

That seems to be something that everyone seems to need to learn for
themselves. We can tell them about it until we're blue in the face (and
I was in Japan and Korea doing just that to CELF folks earlier this
year), but they still don't really believe it until it's bitten _them_.

> The odd I2C device hack of the day the do to one revision of their
> product is likely never to be submitted upstream.  And these
> embedded folks have hundreds of things on that level that they
> sort out for each product, and often very little of it is reusable
> in the next product.

Even that kind of stuff is getting nicer. The device-tree magic we have
for PowerPC boards means that you often don't need any code changes at
all when you bring up a new board -- you just have a device-tree which
describes the hardware. And that covers i2c devices too.

> They don't see the payback for upstreaming this stuff, and for
> a lot of cases neither do I.

They're learning. And we need to too :)

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

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