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. > > Note: As part of implementing DT on ARM, we've also cleaned up and > modularized a lot of code, and created new subsystems and APIs. I think > this is a separate issue, and much of that could have happened > completely independently from doard->DT conversion. Perhaps this would even have been enough. It looks to me that we've created much better, more rigorous processes as a side-effect. I can easily imagine that if we had done all of that but without moving to DT, the end result may have been equally good. I'm not saying that DT is bad. There are a whole lot of good things about it that I really like. On the other hand, I've recently realized that it has become increasingly difficult to upstream even the most trivial functionality because now everybody wants to design the perfect DT binding with the effect of new features not going anywhere. But I digress, and I should probably start a separate discussion about that. > I wonder if DT is solving the problem at the right level of abstraction? > The kernel still needs to be aware of all the nitty-gritty details of > how each board is hooked up different, and have explicit code to deal > the union of all the different board designs. > > For example, if some boards have a SW-controlled regulator for a device > but others don't, the kernel still needs to have driver code to actively > control that regulator, /plus/ the regulator subsystem needs to be able > to substitute a dummy regulator if it's optional or simply missing from > the DT. > > Another example: MMC drivers need to support some boards detecting SD > card presence or write-protect via arbitrary GPIOs, and others via > dedicated logic in the MMC controller. > > In general, the kernel still needs a complete driver to every last > device on every strange board, and needs to support every strange way > some random board hooks all the devices together. I have some difficulty understanding what you think should've been moved out of the kernel. There's only so much you can put into data structures and at some point you need to start writing device specific code for the peripherals that you want to drive. > The only thing we've really moved out of the kernel is the exact IDs of > which GPIOS, interrupts, I2C/SPI ports the devices are connected to; the > simple stuff not the hard stuff. The code hasn't really been simplified > by DT - if anything, it's more complicated since we now have to parse > those values from DT rather than putting them into simple data-structures. > > I wonder if some other solution with a higher level of abstraction > wouldn't be a better idea? Would it make more sense to define some kind > of firmware interface that the kernel deals with, so that all HW details > are hidden behind that firmware interface, and the kernel just deals > with the firmware interface, which hopefully has less variation than the > actual HW (or even zero variation). > > * Would UEFI/ACPI/similar fulfill this role? If I recall correctly, the original OpenFirmware that introduced the DT concept used to have something similar to UEFI/ACPI. Essentially it was possible to not only pass the DT to the operating system but also allow the operating system to call back into the firmware to request service. Of course this brings up the issue about the degree to which we want to rely on the firmware to do the right thing. If it's difficult to update firmware (which it usually is), then we'll likely end up reimplementing some of the functionality in the kernel because firmware might end up being buggy and therefore we can't trust it. On the other hand, one thing that I very much like about the concept is that DT isn't only used as a way to describe the hardware but also uses the notion of services provided by nodes. That means that a DT binding not only defines the properties that characterize hardware but also a set of operations that can be performed on a compatible node. This does not only apply on a per-compatible basis but also depending on device type. A PCI device for instance provides standard services to read the configuration space. Most of this applies to Linux already because when a device referred to by phandle is used by some other device, the phandle needs to be resolved to some Linux-specific object (regulator, clock, backlight...) before it can be used and the given subsystem already defines all the operations that can be performed. So perhaps this isn't really all that relevant after all... > * Perhaps a standard virtualization interface could fulfil this role? > IIUC, there are already standard mechanisms of exposing e.g. disks, USB > devices, PCI devices, etc. into VMs, and recent ARM HW[1] supports > virtualization well now. A sticking point might be graphics, but it > sounds like there's work to transport GL or Gallium command streams over > the virtualization divide. > > Downsides might be: > > - Overhead, due to invoking the para-virtualized VM host for IO, and > extra resources to run the host. > > - The host SW still has to address the HW differences. Would it be more > acceptable to run a vendor kernel as the VM host if it meant that the > VMs could be a more standardized environment, with a more single-purpose > upstream kernel? Would it be easier to create a simple VM host than a > full Linux kernel with a full arbitrary Linux distro, thus allowing the > HW differences to be addressed in a simple way? > > These techniques would allow distros to target a single HW environment, > e.g. para-virtualized KVM, rather than many many different SoCs and > boards each with different bootloaders, bootloader configurations, IO > peripherals, DT storage locations, etc. Perhaps a solution like this > would allow distros to easily support a similar environment across a > range of HW in a way that "just works" for many users, while not > preventing people with more specific needs crafting more HW-specific > environments? That sounds very much like a sledgehammer solution. Also I'm not sure if it would solve all that many problems. I guess what it could solve is to move a whole lot of the underlying specifics of the various SoCs to some other place (the host). It's fundamentally very similar to ACPI, and it comes with the same set of advantages and disadvantages. What will likely happen with such a solution is that we'll have to come up with a standard interface that the guest OS expects. Once that has been defined, vendors will have to implement that interface. Naturally most of them will choose Linux as a host OS. What we'll end up with is unlikely to be any better than the current situation. Vendor kernels that implement the host OS will effectively become forks of their own since there's no incentive to upstream code anymore. Linux upstream becomes a single unified architecture because all interfaces are now the same. Vendors are back to brewing their own. Except for the rare occasions where something needs to be added to the guest interface there won't be much interaction between kernel developers. We will also need to specify stable interfaces between host and guest and I think everyone involved with DT lately has some experience as to how painful that can be. So instead of being able to add new features to the kernel within a single release cycle, we'll likely end up having to wait for a few cycles because it needs to be implemented in both guest and host, which may or may not have the same release cycles. The above is the worst case scenario, but the alternative would be that Linux is still forked into host and guest, yet vendors keep working on one upstream host Linux. In that case, we're not solving anything. All the same problems that we have now will remain. Well, we might be able to make it somewhat easier for distributions, but there are a whole lot of disadvantages to it as well. Thierry
Attachment:
pgpKjxMgkoH1c.pgp
Description: PGP signature
