On Sun, 20 Oct 2013, Stephen Warren wrote: > On 10/20/2013 11:08 PM, Mark Brown wrote: > > On Sun, Oct 20, 2013 at 10:26:54PM +0100, Stephen Warren wrote: > > > >> IIRC (and perhaps I don't; it was really slightly before my > >> active involvement in kernel development) Linus triggered the > >> whole ARM DT conversion in response to disliking the volume of > >> changes, and conflicts, in board files. The idea of DT conversion > >> being that all the board-specific details could be moved out of > >> the kernel and into DT files, thus causing him not to have to see > >> it. > > > > A large part of this was to do with the needs of distros and their > > users - they have a strong need to ship a device neutral kernel and > > to have a reasonable ability to have their kernel deploy on > > hardware unknown to them. Allowing the device tree to be delivered > > with the system rather than have the board configuration in the > > kernel helps achieve that goal. > > Yes. > > I guess one thing I didn't make clear was my hope that whatever > firmware API or VM host implementation exists would be pre-installed > on the system so that distros never had to deal with it, or even know > it existed. That would then transform the many different HW > configurations into a single HW configuration as far as distros are > concerned, since they only target running as firmware clients or VM > guests. Essentially, we are creating a standard platform in SW, which > perhaps is still possible, rather than in HW, which seems unlikely at > present. The idea of some firmware to abstract hardware differences in order to greatly simplify kernel development and maintenance comes up with some regularity. In other words, you are far from being the first one to suggest that. However this needs some reality check. Every hardware system has its share of complexity that the software has to deal with. If that complexity is not in the kernel, it has to be in the firmware. Given we already struggles to have proper and bug free hardware support in the kernel today, even with all the debugging aid and peer review available from the kernel community, I really don't see how you'd manage to make it any less complex in some firmware implementation. If a firmware is involved, that implies a standard API you have to implement your firmware for. And if that firmware API has to cater for different hardware variations and differences, it will have to be very generic and abstract. And the more generic and remote from the hardware details the API is, the more complex the code making the bridge between the hardware and the API will have to be. And if it is complex, it *will* have bugs. Fixing those bugs implies firmware updates which is likely to be just as difficult as bootloaders, if not more, to update in the field. And expecting the firmware implementation to be ready before the hardware ships is almost impossible. Some tradeoff will need to be made in order to meet the shipping deadline which normally implies a lot of pressure from other departments in your company. Most of the time that tradeoff translates into quality reduction in your firmware implementation. There is simply no magic. If some hardware driver needs a year to be top quality in the kernel, then the equivalent hardware abstraction in the firmware would require the same level of development effort. You're only moving the implementation complexity around. And there will always come a case for which the firmware API doesn't cover the hardware needs well, and you'll start adding hardware specific quirks in the kernel directly anyway, or attempt to bypass the firmware entirely for performance reasons. So in theory the firmware idea always looks great. but that works only if the firmware is perfect in the first place and from the beginning. In practice that never works like that. The hardware support in the kernel, on the other hand, can be improved incrementally with time. It doesn't matter if it is not optimal at first. It can be revisited, optimized, reviewed, and sometimes even redesigned. And only when it reaches maturity would be the time to use the experience from the kernel development and make some firmware out of it. But what would be the point then? IMHO the idea of simplifying our lives with firmware is an illusion. Nicolas -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
