| |||||||||||||
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernelKroah-Hartman: AF_BUS, D-Bus, and the Linux kernelPosted Feb 14, 2013 20:11 UTC (Thu) by mmarq (guest, #2332)In reply to: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel by nix Parent article: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel
Forgot!
I don't know why you gentlemn fear or oppose some of this kernel inclusions. It could be modular a compile option, and import little additional maintenance burden... or the opposite, if with those it imports also additional savyy developers.
(Log in to post comments)
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 15, 2013 18:18 UTC (Fri) by nix (subscriber, #2304) [Link]
Uh, no. That's the worst of all worlds, since it implies maintaining two separate bodies of code, in-the-kernel and out-of-the-kernel, where only one of those is likely to get much testing. There's a reason userspace modesetting is generally torn out of X.org video drivers once that driver's KMS support is stable: it replicates the code in KMS in a less capable and harder-to-maintain fashion.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 18, 2013 4:57 UTC (Mon) by mmarq (guest, #2332) [Link]
If you talk DKMS don't worry... it only have to provide decent support and not even DKMS itself... then any distro on earth will DKMS you in the face every time... sorry, ***but is exactly what they do already***... you don't use Linux or you build from scratch... the possible conclusion...
ummm... stange agendas !... DKMS is exactly a good idea for the overburden complains. Don't know why Kernel devs must maintain every thing about drivers... lots of bickering yet it already imports firmware blobs, when there could be a proper interface (discussed/DESIGNED case to case of family, and parts of DKMS changed accordingly)...
Then the more generic stuff goes kernel maintenance... APIs don't change that often(matter of fact quite unoften for many tastes)...come on you know its truth!... and the burden to support every single variant of a hardware family goes to the vendors... like half half...
Free drivers could co-exist with proprietary,*** which they already do***, so nothing new and nobody got hurt, and if properly designed, more things could be open and free drivers use a lot of the same stuff of the proprietary ones without the need to be a mess of half finished things and proprietary drivers that break at every 2 versions...
And if security bitching is a concern, why not direct the program caging and sandboxing to the DKMS side and really support it, instead of shoving it to the unsuspected user, that by no dreams will ever be using NSA grade...
About KMS it makes good sense in userspace... the reason is that consoles will also want to use the possibilities, kernel interfaces directly, so its sensible...
The other arguing, maintenance, stuff... issues... preferences... tastes...particular visions.... semantics for pointless bickering.
10 years and little change to many things.. oh! well, progress is not painless... action counter-reaction applies here to... (damn politics!)
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 25, 2013 17:02 UTC (Mon) by nix (subscriber, #2304) [Link] The other arguing, maintenance, stuff... issues... preferences... tastes...particular visions.... semantics for pointless bickering.So... not having to implement everything twice is 'semantics for pointless bickering'? Ooh-kay.
|
|||||||||||||