Device trees as ABI -- flag the stable ones
Device trees as ABI -- flag the stable ones
Posted Aug 15, 2013 2:34 UTC (Thu) by mmarq (guest, #2332)In reply to: Device trees as ABI -- flag the stable ones by dlang
Parent article: Device trees as ABI
What is the fundamental difference in principle ?
> One way to do this is to do a cut-n-paste of an existing driver, change some constants and create a new driver.
> The other way is to take the first driver, change the constants to DT parameters (defaulting to the old constants if not defined), and then you don't need yet another driver.
Isnt exactly how is done today ? ... if yes, why doesn't it work ? (meaning maintainers drown in load, implementers complaining etc )
> arguing that there should be a stable ABI isn't going to get you anywhere. It's not something that can be implemented on a per-driver or per-subsystem basis because part of the ABI the driver would need is the kernel locking rules, power management interfaces, and other things that affect the entire kernel.
After all it was a "piss off" your earlier post lol
I don't want to go anywhere, i'm not an implementer. But if that is true wouldn't be the entire kernel the ABI ? lol and there wouldn't be possible to device other ABIs without starting from scratch. I don't think that is the case.
I think what you say is not possible, is already done by DKMS. Every distro i use, uses DKMS, though is not officially supported(AFAIK).
I think the basic is NOT a question of code but more a question of perspective. You dared to mention the "free candy" of upstream "free maintenance" and why complain... i dare to mention the "corporative interest" in keeping everything in house (so to speak), even when everything in house comes very short in lot of aspects and why these complains.
Employing logic, what i said is, if DMKS works, and it does otherwise no distro would use it, why not improve that tremendously, harden it, not one but several DKMSs... i mean, it could have some rules different according the subsystems addressed, it could use Dbus, it could use capabilities for safety... etc.. the genius of programing wouldn't take long advancing several innovative mechanisms, inclusive interacting with DTs in a way that would ease maintenance by a great deal...
The "plus" for perspective is that it would follow the "LOGIC", a lot of drivers are almost identical... but not quite... what is identical will be kernel, what could vary, is a low level "module" that could be dynamically loaded (like DKMS), and that could be in binary form (as happens with DKMS), and is more logic and sane because the "not quite" means every device could/should/must have its own low level module, and it would be good even for the all OSS drivers IMHO.
Is this an ABI ? ... is this a long (put long in this, only change if no other choice) stable API ? ( a bit like kernel 3.10 prespective lol)
Posted Aug 15, 2013 2:52 UTC (Thu)
by mmarq (guest, #2332)
[Link]
Oops... i meant "a lot of *devices* are almost identical"... not *drivers* ... the sentence above doesn't make sense, drivers should follow the devices, not devices following drivers ( what some Linux aficionados seems to want)
And in reality there can be quite a lot of differences even for devices implemented around the same processing element (NIC, sound, graphics, storage etc)
Posted Aug 15, 2013 3:25 UTC (Thu)
by dlang (guest, #313)
[Link] (3 responses)
> What is the fundamental difference in principle ?
If you say that the drivers must exist, then the status quo is fine, but if you say support for the devices is what must exist, then there is a lot of room for cleanup in the existing code.
>> The other way is to take the first driver, change the constants to DT parameters (defaulting to the old constants if not defined), and then you don't need yet another driver.
> Isnt exactly how is done today ? ... if yes, why doesn't it work ? (meaning maintainers drown in load, implementers complaining etc )
this is part of the problem today. Far too many of the existing device drivers in ARM (and to be fair, in other embedded architectures) are cut-n-paste jobs when they should be consolidated.
Maintainers haven't been pushing back enough. This was one of the items in the discussions that triggered the "the linux-kernel list is not professional" a few weeks ago.
> ...wouldn't be the entire kernel the ABI ?
> I think what you say is not possible, is already done by DKMS. Every distro i use, uses DKMS, though is not officially supported(AFAIK).
DKMS also fails somewhat regularly as the kernel internals change. This is also why the nvidia and ATI proprietary drivers frequently don't work with a new kernel. The changes made elsewhere in the system can frequently break modules, especially ones that are as demanding as the video drivers.
Yes, it would be possible to create a module API that would not need to care about some of this stuff, but it would be far more limited in what the module could do and how well it could do it. The kernel developers have opted not to go this route (see the stable ABI nonsense document if you aren't familiar with it)
the only time I've seen DKMS actually used is for vmware drivers. The various distros may include it, but I don't see them using it much.
DKMS "works (mostly)" pretty well for minor kernel updates (distro kernel patches), but if you try to use it across larger updates, you will see how badly it starts to fail.
Just because something is popular, doesn't mean that it's the right thing to do. The situation where lots of people were running nvidia modules, and so suffering kernel crashes and as a side effect running into problems with KDE config file updates disappearing on them a year or so ago is a good example of this.
> The "plus" for perspective is that it would follow the "LOGIC", a lot of (devices) are almost identical... but not quite...
actually, in the ARM space, this really is the case. A lot of the different drivers are for the exact same thing connected at a different address.
This does fall naturally out of the 'normal' embedded development process, where a programmer is assigned to make Linux work on chip/device X, and frequently all the company cares about _is_ making it work on that chip/device. once that chip/device ships, the programmer never expects to deal with it again, so they don't care about upgrading things. For these people, the cunt-n-paste, modify constants approach is just fine.
This is part of the oft-repeated claim that "embedded is special, it shouldn't have to follow the rules"
However, the Linux-kernel developers have to maintain things over the long run, and many of the larger companies doing embedded development are starting to learn that they really do want to have the support upstream so they don't have to repeat the driver development for the next kernel/project.
As ARM is stabilizing, they are working to clean this up, but it's a lot of work, and Device Trees are a very significant part of that cleanup.
Posted Aug 17, 2013 6:41 UTC (Sat)
by mmarq (guest, #2332)
[Link] (2 responses)
Yes its a shame...but don't have to be that way.
DKMS as it is, is too must encompassing, its not harden (no fail safe fall backs), and it has no security but what the kernel provides( could have capabilities as example). The DKMS i had in mind is much more restricted, much more things that are "generalist" in a POV could be "in the kernel", so the chance of breaking something in the DKMS APIs would be more diminutive, and since it could be officially maintained, those APIs could also be "extended" according to Kernel changes... and most of times without breaking old stuff... i think...
Sorry for the too much pragmatic views... but i've always been trained that to better solve a problem is to think outside the problem, not to live with it.
Posted Aug 17, 2013 9:59 UTC (Sat)
by dlang (guest, #313)
[Link] (1 responses)
Posted Aug 19, 2013 13:00 UTC (Mon)
by mmarq (guest, #2332)
[Link]
Its not a question of code but more a question of design philosophy. It would had to be the maintainers of the subsystems addressed that know more (should) than anyone else how things in their side work, to give you an answer. But the philosophy which i think is quite pertinent and true, is that the answer can vary according to the subsystem, this generalist approach may not be the best approach.
I'm starting from the principle that a device, can have things different even from devices of the same family, firmware, bus characteristics etc
So if we agree in this point which seems to me very logic, and very true, the idea is quite simple, what could be "discrete and unique" goes DKMS like, what could easily be addressed in a generalist way is "in kernel" (modules or other doesn't matter).
And in this *logic* (which sometimes is missing from OSS due to politics), this DKMS should be different from subsystem to subsystem. Userland drivers perhaps wouldn't need DKMS anything i think, and it will be for the maintainers to "draw the line in the sand" for the different *long term stable APIs* that would be dynamically exposed by this DKMS, APIs that could have capabilities to restrict to where they "talk/interact" with the kernel, and even how they talk among themselves... that is why i talked of several DKMS not one, more so because different subsystems could have different "lines in the sand".
Would there be worries about locks (and other things) ? ... don't know... i think the maintainers would have the last word, but it would be nice to hear the implementors/vendors/IDMs.
And is not about allowing closed sourced blobs in the kernel, matter of fact OSS drivers for a lot of devices could use the "new DKMS" scheme, matter of fact every pertinent device (falling in the category that apply), should use the "new DKMS" either the source is available or not (its about predictability, and the logic of unique vs generalist characteristics)... and if hardened with a safe fall back, this "new DKMS" could be even grand for OSS driver development (and proprietary to), and cherry on top of cake, due to predictability, to reverse engineer if the case comes along.
In a "political" view that is what i call allowing some privileges, but take advantage of it lol.
Device trees as ABI -- flag the stable ones
Device trees as ABI -- flag the stable ones
Device trees as ABI -- flag the stable ones
Device trees as ABI -- flag the stable ones
Device trees as ABI -- flag the stable ones
So what would this "new DKMS" dynamically load ?... not sure... but not much more than load the firmware and a low level driver that initializes the devices and exposes the very low configs to the kernel.