On Wed, Dec 04, 2013 at 11:03:12AM -0800, Greg KH wrote: > On Wed, Dec 04, 2013 at 06:43:45PM +0000, Mark Brown wrote: > > If you look at the hardware design decisions this stuff tends to be > > totally sensible; there's a bunch of factors at play (complexity, area > > and isolation tend to be other ones). There's a lot of the stuff that > > we're complaining about where they can reasonably question why this is > > so complex for us. That doesn't mean that everything that it's possible > > to do is sensible but there's definitely limitations on the kernel side > > here. > The main reason it's so "complex" is the drive for people to have a "one > kernel image for multiple systems" and hence the need to have DT handle > all of this. I don't think that requirement has been pushed back on the > hardware engineers yet, and they are still thinking that a custom image > per chip is ok. No, the single system image stuff is orthogonal here and is basically irrelevant for many use cases - it's essential for servers and so on but most consumer electronics guys pretty much don't care and this stuff is as much a problem for them as anyone else. We've always struggled with these things even when building for specific hardware, DT is just another way to write the data structure here. When people are talking about figuring out the DT first here what they're taking about is as much working out what we need to abstract first as anything else. This isn't a million miles away from the stuff we've dealt with using probe deferral in terms of fitting into the device model, at least at a high level, though it is harder to sidestep the issues here. > > These firmwares have tended to be ROMed or otherwise require expensive > > validation to change for sometimes sensible reasons, keeping the amount > > of code that's painful to change low will tend to make people happier if > > a change is needed. Most people like the risk mitigation. > I love it how it's so easy to make the kernel be the part of the whole > system stack that is simpler to change than any other :) Dammn open source license :) > I'm all for making Linux be the "firmware" and deal with these very > low-level issues directly, but again, this drives in the face of your > self-stated goal of "one image per architecture" for the kernel. You > kind of can't have it both ways it seems, so someone needs to make up > their mind as to what it's going to be... I think you're confusing me with someone else... in any case, I don't see why there should be any conflict here.
Attachment:
signature.asc
Description: Digital signature
