Device trees as ABI -- flag the stable ones

Posted Aug 17, 2013 6:41 UTC (Sat) by mmarq (guest, #2332)
In reply to: Device trees as ABI -- flag the stable ones by dlang
Parent article: Device trees as ABI

> 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 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.

Device trees as ABI -- flag the stable ones

Posted Aug 17, 2013 9:59 UTC (Sat) by dlang (guest, #313) [Link] (1 responses)

so how exactly is your super DKMS going to figure out that the module now needs to do locking because the code that calls it no longer grabs a lock (a standard thing to happen as locks get more fine-grained)?

Device trees as ABI -- flag the stable ones

Posted Aug 19, 2013 13:00 UTC (Mon) by mmarq (guest, #2332) [Link]

I don't know.

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".

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.

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.