Re: [fedora-arm] ARM summit at Plumbers 2011
David: On Wed, Aug 24, 2011 at 6:55 PM, da...@lang.hm wrote: ARM is currently in worse shape than the PC market ever was in this aspect, but in this case it's less a matter of getting the hardware guys to change what they do than it is to get better documentation of what the hardware is really doing and not duplicating drivers for cases where the right answer is just replacing a constant with a variable (just as an example of the very common case where the same component is wired to a different address) I agree. Maybe Linaro or an equivalent organization could provide a ARM kernel janitor service to the community, where they refactor existing ARM platform/driver code to make it more common. This is something that's difficult for a single person with experience in only one or two SoCs to do, but it would be pretty straightforward work for a team of three or four people with broad coverage of the SoC devices the kernel supports now. As such refactoring consolidated larger and larger chunks of kernel code, new designs would gravitate towards those consolidated implementations because they would be the dominant references. b.g. -- Bill Gatliff b...@billgatliff.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [fedora-arm] ARM summit at Plumbers 2011
Russell: On Fri, Aug 26, 2011 at 11:35 AM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Fri, Aug 26, 2011 at 11:11:41AM -0500, Bill Gatliff wrote: As such refactoring consolidated larger and larger chunks of kernel code, new designs would gravitate towards those consolidated implementations because they would be the dominant references. Don't bet on it. That's not how it works (unfortunately.) I wasn't being clear. The Linux community isn't large enough to dictate to ARM SoC designers how their hardware should work--- mostly because the Linux community doesn't buy chips, corporations do. And it has been my experience that the parts of corporations that negotiate deals for the hardware aren't populated with the developers of the drivers for said hardware. What I meant was that as new hardware becomes available, if we have strong driver models then driver authors will adopt those APIs rather than inventing their own. I'm thinking about GPIO before gpiolib, for example. Or the current state of PWM. This need to be different is so heavily embedded in the mindset of the hardware people that I doubt providing consolidated implementations will make the blind bit of difference. I doubt that hardware people coming up with these abominations even care one bit about what's in the kernel. I don't routinely see a need to be different as existing strictly for its' own sake, even with the hardware guys. Rather, I see a lot of developers (hardware and software) that are so consumed with their own requirements and deadlines that they don't get the chance to step back and see the bigger picture. The resulting fragmentation is a symptom, not the disease itself. And honestly, some of the fragmentation is a really good thing. I love how Atmel does their GPIO controllers on the SAM-series parts, for example. The SODR and CODR registers are a godsend for concurrent code. We wouldn't have such treats if everybody did things the same way. So I'm generally ambivalent to the hardware situation. But that doesn't mean that the software has to be equally fragmented. In fact, I think the hardware situation necessitates that we pay particular attention to NOT fragmenting the drivers for said hardware. Gpiolib proves that is possible, something I didn't think I would find myself saying when David Brownell started his effort. I'm glad he proved me wrong. b.g. -- Bill Gatliff b...@billgatliff.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [fedora-arm] ARM summit at Plumbers 2011
Luke: Step back from the keyboard just a bit. :) It's true that the glass isn't completely full--- but it's pretty darned full! And we wouldn't be discussing the various GPL and other violations that you cite were it not for the overwhelming successes of Free Software, ARM, Linux, and Android. We are well past debating the merits of Free Software et. al, which itself is a huge milestone that we need to recognize. Now it's time to let the lawyers do their jobs. And they will, because there are tremendous sums of money at play. Money that wouldn't be there if it weren't for us developers. But we need to stay out of their way, while at the same time taking care to continue producing tangible things that are worth fighting over. As developers, we've won. Deal with it. Revel in it. And then get over it. I have observed all the hand-wringing regarding the state of ARM Linux, and it's obvious to everyone that there is still work to be done. ARM isn't like PCs, and that's obviously inconvenient for Linus but it's an essential part of ARM's success. Russell King has been overworked for a decade or more, attempting through sheer force of human/developer will to keep ARM Linux from running off the rails. As far as ARM Linux is concerned, I think we're dangerously close to being smothered by our own success. We have to learn to work smarter, because we can't work any harder. And I applaud Linaro and the countless others for recognizing this problem and looking for ways to resolve it. I for one would love to participate in the ARM Summit, but I'm a sole proprietor without an expense account to charge the travel costs to and they are too large for me to carry personally. I suspect I'm not the only one in that situation. The fact that there has been little response to the ARM Summit doesn't mean that nobody cares or that the problems seem to large to solve. It just means that we're going to have to find a different way to get this work done. b.g. -- Bill Gatliff b...@billgatliff.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
