Recent Features
| |||||||||||||
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernelKroah-Hartman: AF_BUS, D-Bus, and the Linux kernelPosted Feb 14, 2013 5:48 UTC (Thu) by brouhaha (subscriber, #1698)In reply to: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel by Cyberax Parent article: Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel I'm not sure about VT handoff or interaction with V4L, but none of the other features that you've mentioned are especially better due to being in the kernel. There are suitable mechanisms for all of them for user-space processes. If there weren't, we'd invent some. If VT handoff or interaction with V4L have some particularly tricky requirements, then perhaps doing those from userspace might need some additional infrastructure. I'm not saying that I think we should go back to exactly the same userspace graphics code we used to have. There were definitely things wrong with those. However, moving chunks of it into the kernel isn't the only way to solve the problems we had. Userspace GPU drivers never performed well.That might be true, though I never personally had any significant performance issues with them. But even if it was true, I don't think there's anything inherent to the problem that prevents it from being done in userspace with performance comparable to what we get in kernel space. That's certainly what we found at the very big router company. There's nothing magic about being in kernel space that makes code run significantly faster. Certainly in user space you need to avoid doing things that involve copying memory from one process address space into kernel space then again into another process address space. Naively designed code tends to do a lot of that, but it's quite possible and not even that difficult to avoid it by using modern OS facilities. Besides, all this shiny new GPU infrastructure allows to kill off stuff that REALLY should not be in the kernel: VT102 emulator for kernel framebuffers.I'd be perfectly happy to have neither in the kernel, but if I had to choose between one or the other, I'd definitely keep the relatively small, simple, lightweight VT102 emulator in the kernel and put the big, complicated GPU stuff in user space. I never expected anyone to take my comments about this very seriously. I don't have the time or inclination to work on GPU drivers. The people that actually do the work get to make the technical decisions about it, and I wouldn't have it any other way. This is just an exercise in being an armchair quarterback.
(Log in to post comments)
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 14, 2013 5:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
> There are suitable mechanisms for all of them for user-space processes. If there weren't, we'd invent some.
Please, go and educate yourself. GPU interaction requires an always-on privileged process that should be able to talk directly with hardware. If this process crashes you can easily get a hard system lockup.
Oh, and this process must be able to get _exclusive_ access to the hardware. Because it intrinsically can't be shared.
Does it start to sound familiar? No?
> I'd be perfectly happy to have neither in the kernel, but if I had to choose between one or the other, I'd definitely keep the relatively small, simple, lightweight VT102 emulator in the kernel and put the big, complicated GPU stuff in user space.
The kernel-side drivers basically manage video buffer allocation and command submission. I.e. they take buffers with command batches and send them to hardware. They don't do anything that is fundamentally complicated.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 14, 2013 6:15 UTC (Thu) by brouhaha (subscriber, #1698) [Link] If this process crashes you can easily get a hard system lockup.So? If a kernel driver crashs, you can easily get a hard system lockup. Been there, done that, got the T-shirt. I've been device driver developer on various flavors of Unix for more than 20 years. Putting code in user space doesn't magically make it less robust, any more than it magically slows it down. If you want robust code, you have to design it well, regardless of whether it's in kernel space or user space. Have you actually SEEN the GPU drivers?As a matter of fact, I have looked at the GPU drivers, and they seem a lot more complicated than the VT102 emulator to me.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 14, 2013 8:47 UTC (Thu) by mmarq (guest, #2332) [Link]
well i'm not "device" driver developer... and what you say seems more or less reasonable for a device...
i suggest http://hsafoundation.com/ a tour by the specs and docs...
quite a list and quite heavy weights no ?
So what seems to stand out against your arguing in my view... even without deep tech arguments that i don't have now(if i ever)... is that is NOT about "devices" anymore but "processores"... yes talk GPU talk processor...
And none of other contender to this spec will be out... matter of fact Intel already has big "physics" cards... Apple neither will be in the shadow... all this things are/will be **fully programmable**.
It is a wonder some news about gaming in Linux... when some of its developers seem to want to keep it 3th class in the sector... boy! it is a luck to have game studios interested...
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 14, 2013 8:13 UTC (Thu) by mmarq (guest, #2332) [Link]
"" I'm not saying that I think we should go back to exactly the same userspace graphics code we used to have. ""
Uff!... thank god! lol
I want the tremendous *compute power* of the GPGPU ... i want the ability to do "co-designed" on-the-fly binary translation with profiling for that compute power... i want all my graphics ray-traced for illumination, with OpenCL style physics effects ( hey! why not a KDE or Gnome environment with "physics" effects and animations ?... not only games ??)
quite a list no!? ... i think doing all that from userspace would make programing Cell look like superball.. lol
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 14, 2013 18:01 UTC (Thu) by nix (subscriber, #2304) [Link]
Actually almost all of the computation side of things *is* done in userspace. It would be madness to put LLVM into the kernel!
But things like physical memory management and mediation between competing users -- that's what kernels *do*. It's what they do for the realm the CPUs rule over, and it seems perfectly sensible to have them do it for the GPU's realm too (and a heck of a lot more robust than the alternative).
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 14, 2013 19:39 UTC (Thu) by mmarq (guest, #2332) [Link]
Don't follow, who said about puttin LLVM into the kernel ?
If traces parallels with Android model, yes they might adopt something like Aparapi (translates Java into OpenCL like, with knowledge of target ISAs) and push for a backend compiler or "finalizer" into the kernel.
But this is quite smaller than LLVM and resides below LLVM...quite low level.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 15, 2013 18:15 UTC (Fri) by nix (subscriber, #2304) [Link] Don't follow, who said about puttin LLVM into the kernel ?You did. The 'tremendous compute power of the GPGPU' is implemented by compiling things targetted to the GPU, via LLVM (at least that's the lion's share of it). Putting that in the kernel means putting LLVM in the kernel.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 18, 2013 4:21 UTC (Mon) by mmarq (guest, #2332) [Link]
he!..wrong.
I'll try in lay terms (warning: NOT a developer of this)
The HSA standard if that is what we are following, doesn't need kernel inclusions... i'm confident... not even the runtime... only the "finalizer" that touches metal directly could induce the need.
This back-end compiler is very ISA specific, is its job->knowing well the target and optimize for it with runtime info, its a JIT compiler, things that static compilers cannot do(well), even LLVM that sits above;
So most probably will be several different "finalizers" for the many "processores" HSA encompasses, including not only ARM/AMD/Imagination GPUs but also TI DSPs etc.
So it could be a DKMS feature, if Linux supports DKMS properly(?)...
Matter of fact it doesn't even have to be a "finalizer", the HSA runtime can take care of that like the OpenCL runtime or the C++11/AMP runtime does.
For the more performance aware version with a "finalizer", the only features that touch hardware are DMA(direct memory access), VM stuff, TLB stuff, scheduling and IOMMU stuff... things that seem not indicate GPU at all no ?...
And it could be done by improving what is already there... i don't think the patches must be intrusive if it comes to that, since the hardware features listed on the spec are really very small.
Matter of fact the basic spec seems like any other language, with its proper runtime... and i don't see the need for C or C++ libs on the kernel(?)... neither should this, tough its idiom HSAIL, is very low level and compatible with LLVM IL SSA, that is, it takes SSA transforms it to HSAIL then native by a "finalizer", this if you want your program having the same Virtual Memory space, meaning CPU + GPU/DSP/etc will have the same space for better integration overall... then the "finalizer" is the way to go...
OTOH it can also proceed directly from the IL to the target by the runtime, and a program can be build with both targets by their tools, native + HSAIL(finalizer), using exactly the same code, so even if Intel NEVER implements the hardware features, any HSA program could run on any Intel CPU *platform*(so far) **UNCHANGED**...
Only with the "finalizer" stuff, the program can run quicker in perhaps most cases(if properly coded)(less heavy or less specific stuff and suspect no difference at all)...
The idea is not only use the same *virtual memory space*, is use ANY language to program it... and much better than nVidia CUDA IMHO... it goes so far to support, C/C++, AMP, OpenCL, fortran Java(+scripts) Python and more, i think more than the supported natively by LLVM...
The advantage with a "common virtual space" is that any GPU/DSP/etc memory will be managed as system memory not a different pool... also the GPU/DSP/etc could have its context/exception handling and interrupt handling mostly outside of any CPU control (like if it were another CPU), which is better for power management... its a UMA heterogeneous SMP architecture, an obvious very good evolution to the co-processor idea...
intros
The drawback with this is i don't know if its compatible with the current DRM implementation, or if it can be patched to it, since rendering seems only one of the features that encompasses the standard, it could be complementary... or perhaps!... Intel top management, namely its CEO gets one of those Christmas Ghost moments, and Intel joins the HSA... eh!... without need for false promises to the ghost lol... since Intel doesn't need to license anything (i think), it only have to make its hardware features compatible -> then there will be no bickering but a patch flood... lol
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 18, 2013 4:28 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
Basically, yet another pie-in-the-sky project from purely academic guys without real hardware?
Yeah, it will immediately beat all other architectures, sure.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 18, 2013 5:07 UTC (Mon) by mmarq (guest, #2332) [Link]
Samsung, ARM, TI, Sony, AMD, Imagination, LG, STMicro, ST Ericsson etc etc etc... are academic guys without real hardware ?
Sorry but you are babbling nonsense... without ever having toke a pick on anything...
Only Samsung itself is bigger than Intel, and its not only IT stuff, Samsung and LG makes perhaps the majority of the consumer electronics world...
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 18, 2013 5:23 UTC (Mon) by mmarq (guest, #2332) [Link]
oh! forgot
*Sony*, Samsung, LG... IT IS *THE* consumer electronics world...
You better say "i don't want Linux on those things"... hard task to fulfill no doubt... and the new Playstation IV, you also don't want to see it with a Linux OS ??... doubt they will ever license Microsoft, or (M$ would accept)...
Well, PS IV is going to be HSA modeled... is not PowerPC, is x86 AMD, and Sony entered the HSA... the academic guys grow up and made real hardware lol ... and a flush of shills entered the Linux forums, or is that veterans went to sleep... or are pesky politics abounding ... ummm !!?..
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 19, 2013 19:25 UTC (Tue) by khim (subscriber, #9252) [Link] Well, PS IV is going to be HSA modeled... is not PowerPC, is x86 AMD, and Sony entered the HSA... Wow! Looks like SONY just can't ever produce nice, easy-to-program console. After Cell fiasco (which is theoretically so much more powerful then XBox's CPU but so hard to program that most PS3 game ports are inferior to XBox360) then decided to use of-the-shelf-hardware but now they want to still screw the developers in some other way? I wish them luck, they'll need it.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 19, 2013 22:50 UTC (Tue) by mmarq (guest, #2332) [Link]
Funny you say that, because Microsoft and Nintendo, decided exactly the same thing... so by your POV their are all up to screw the developers! lolzz...
Sony should not be about nice and easy to program... it would be nice for a change... but primarily Sonny i think is after "PERFORMANCE"(try to match both the why of HSA)
See!?... the reason is simple, many bickering in hardware/review sites... but its seems CLEAR that if you want performance, PERFORMANCE IS IN THE SOFTWARE... arguing this CPU and that processor is best than this or that, only controversy to entertain morons!... it is best but with what software ???
More!... according to a leak that circulates, the Durango GPGPU that goes for the Xbox720 is very unusual and seems a highly customized design... many still do laugh and foresee the doom of Xbox, but that is what Microsoft choose, perhaps fitting better their tools and their programming paradigms... since its clear PERFORMANCE IS IN THE SOFTWARE, its highly premature to judge anything only by the hardware features alone...
So your argument of "off-the shelf" is simple WRONG by many accounts... and you should applaud because gives the software side much more leverage.
But i understand your point about "off-the shelf", the "traditional" world of graphics and video is just too stupid to begin with... with super bloated Driver an VM JIT layers for the GLs of the GPGPUs -> crazy!, usually those Console guys **program much more to-the-GPGPU-metal** and are able to extract an **order of magnitude (10x) more performance** than in the "PC world"... Microsoft is in the same boat some how, Xbox and Microsoft will be around *compute* and C++AMP allover...
LINUX IS NOT ABOUT "COMPUTE POWER", AND POWERS SEEMS NOT WANTING IT TO BE... that is why client side "mass adoption" concerning (it has to do with graphics/video)... Microsoft will win for Linux in the foreseeable future, and history repeats itself... even when they F### up as they did with Windows 8...
Sounds crazy but its true... and there is where HSA foundation entered... the idea is exactly "facilitate" this, open it to general languages, and that is why it catched so many interest and is a "de-facto" and "de-jure" standard right now.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 20, 2013 17:54 UTC (Wed) by khim (subscriber, #9252) [Link] usually those Console guys **program much more to-the-GPGPU-metal** and are able to extract an **order of magnitude (10x) more performance** than in the "PC world" This one phrase says it all: bollocks. If you ever actually go and compare console versions of games and PC versions of the same you'll see that yes, they achive "10x more performance"... by replacing nice textures with tesselation and other niceties with blurry POS. Hardly an achievement worthy talking about. I think I'll side with viro: this is not a slashdot and since effective discussion with you is impossible I'll just use this nice LWN's feature and silence you in my stream. Have a nice day.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 20, 2013 22:17 UTC (Wed) by mmarq (guest, #2332) [Link]
hey! the discussions is not me, don't try to make it personal.
I even can agree with some things you say, but everything must be in its proper context, and those are not fixed, they evolve tremendously...
Its not to hurt feelings, to make controversy... but the idea i trowed about forking the Linux Kernel... as exposed... perhaps are not off base.
And i'm not the right person to answer most things, i'm sure the HSA have ppl around here, they could answer erroneous ideas if they are "allowed"... perhaps in another thread...
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 21, 2013 8:11 UTC (Thu) by elanthis (guest, #6227) [Link]
If you compare equivalent hardware, yes, we do make way more use of the hardware in consoles than PCs. This is entirely because we are targeting a fixed hardware spec, though. PC versions can be better because you're comparing 2013 era PC hardware with 2006 era console hardware, which is why mmarq's argument is flawed even if he has a glimmer of insight in his rambling.
There was some AMD buffoon who clearly only knew consoles claiming that D3D12 would likely do away with most of the API since developers wanted to directly target the hardware. This is obviously impossible in a world with multiple GPU vendors, and even things like AMD replacing its machine code format in its own product line.
Also, we don't _want_ to do this direct hardware coding so much as we _have to_ to make sure the games we put out in 2012 looked better than our competitors' games in 2008 despite using the exact same hardware. We have to push micro-optimizations and tricks to improve performance because the hardware is locked in the stone age.
Consoles can be faster than an equivalent PC because we have no real OS and can micro-optimize in ways that PC/phone developers can't. This is not a good thing, for developers or users. Users want diversity and competition, and developers want easy APIs that make development cheap and efficient. Consoles do neither.
Meanwhile, real PCs can massively outperform consoles because for all the bloat, the hardware is massively more powerful, partly because many companies can compete to make the best hardware and users can and do upgrade at will. So mmarq's argument is just silly. Hardware does bring massive performance improvements, and software trickery is about making the most of limited hardware.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 21, 2013 9:18 UTC (Thu) by khim (subscriber, #9252) [Link] The only games which "make way more use of the hardware in consoles" are exclusives like Uncharted where you really can throw away all these HSA discussions and code to bare metal. Most cross-platform games (and very few games are exclusives nowadays) are better in XBox360 because it's hardware is closer to PC and usually you don't need 10x more powerful PC to beat the console game in quality (2x is more then enough) which implies that these "micro-optimizations and tricks" are not all that popular. They are used in some "computationally heavy" places (because otherwise game will just not work on console) but most of the time it's just plain simple reduction in quality (number and size of textures, etc) till you have the required FPS. And of course there are no HSA or "bare metal" access: it's OpenGL or Direct3D on consoles, too.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 18, 2013 5:51 UTC (Mon) by dlang (✭ supporter ✭, #313) [Link]
oh, you mean all those devices that I cannot run a current version of the OS on because the vendor drivers don't work, or are not made available.
These vendors are examples of where things are not working, not examples that we should be following.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 18, 2013 8:23 UTC (Mon) by mmarq (guest, #2332) [Link]
Don't worry life always finds a way...
I don't know what is the politics of HSA what they decided... but i think they have serious problems... and drivers is not the only concern...
They must have an *Open OS*... for their *Open Standards* -> they are open, all GPL compatible(Double licensing may be used, but also BSD style is used and not only LLVM)
IBM is not in it(doubt ever will, its not its targets, unless they pass to use GPGPUs and stuff for computation, which also doesn't make much sense for them )...
Apple though based on ARM will not go for it, open their OS, even if they join...
Microsoft the same or worst...
BSD are too lacking for "devices & stuff" and getting obsoleted by Linux
*\\It remains only Linux//*
More than drivers, i think it would be wise to see if they could build ALL of an OS, if not almost all of a Distro, using their very comprehensive compiler toolchain... and which could very well be ***much more ARMv8 64 bit centric than x86***.
GCC is in a paradox crosswords as reported by Pharonix, Intel ICC is too CPU centric and will remain as foreseeable, even if they open source it, and worst doubt they will ever target ARM...
Since they set Most of Industry, including the leaders of the client side of computing, ARM Samsung & CE, to build a top nosh compiler toolchain designed specifically for this... one natural candidate might be Android...
But i can't see if Google is up to it, they may decide to go a little like Apple/M$ and target primely their stuff... its Linux based, its some proprietary to, and they might NOT be to take the BURDEN...
HSA is big, they can do it...
So what only remains is fork the Linux kernel itself... I SEE NOTHING HOSTILE IN THIS... IT WOULD BE EXACTLY LIKE *ANOTHER* DISTRO BUT ONE THAT WOULD GO MUCH DEEPER THAN THE USUAL, WITH THE APPLYING PATCHES NOT APPROVED/WAITING MAINLINE... ALL DISTROS DO IT MORE OR LESS...
In the end LF and Linux can also benefit from it, it will be like another branch, and it already maintains several, so another one maintained elsewhere doesn't hurt... and build with HSA CC, and with its driver interfaces, which could be DKMS++ based and used also by many other distros ... and who knows if not useful in the future, who knows about GCC -> can it evolve ?
I'm afraid with the politics not all is rosy, or if anyone can ask more than the remarkable work that has been done so far by the LF, but when the HSA compiler collection is finished, they must find a real USEFUL solution and they would want to really test it with an OS... they will have no other choice, but to find that solution -> you simple don't waste a lot of time expertize and money building something and then not use it...
Don't know politics, but i see it like an addition... not something bad... distros, for everyone that flanked along this years, 2 more seemed to have popped out in its place, many with many peculiarities, everyone trying to be different... what would be the danger of having another one ??...
It would be not an attempt to take over... matter of fact i think exactly like any other distro, they would link LF attentively and try to participate, only they could go very different in a lot of changes...
The GPL is not really suitable for "exclusivity or my way or the highway kind of approaches", who ever thought of that must be desperate or in deep delusion...
In the end i don't know the decisions... but also i don't see many other options...
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 18, 2013 9:12 UTC (Mon) by mmarq (guest, #2332) [Link]
"exclusivity or my way or the highway kind of approaches"
I mean it is used, and could be used extensively... but doubt it will ever produce any political results for any particular agenda or impediments to others... besides exactly a cave-in choice from the producer... and doubt any "forcing" effect in any sizable receiver
That could have worked more or less for the type of distros he had so far... and even so not all... and none in strict patch software feature choice..
Linux as been protected by the inherent complexity from fork pressure and be able to dictate...
Android breached that somehow... in the future it can be much worst... and its not only about HSA...
So i find this comments about "my way" kind of vision and we should pursue this and not that very amusing... probably not conscious kernel devs, if one at all... and the case is you should pursue what you think best, but abstain from such comments.. lol...
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 19, 2013 19:25 UTC (Tue) by khim (subscriber, #9252) [Link] Samsung, ARM, TI, Sony, AMD, Imagination, LG, STMicro, ST Ericsson etc etc etc... are academic guys without real hardware ? Nope. These are companies which cough up few millions here and there to make sure they'll be in the loop if this idea will actually reach some usable stage. Does not mean anything beyond that at this point. Remember the last "next big revolution" (called EPIC if you forgot)? It also had an impressive names: Intel, HP, IBM (which wanted to use the opportunity to unify UNIX), etc. They had really awesome slides! And really cool story. I'd say EPIC story. In the end we've got an epic fail, nothing more. I'm not saying they'll fail but the fact remains: number of supporters and sizes of such supporters don't automatically equal success.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 19, 2013 23:41 UTC (Tue) by mmarq (guest, #2332) [Link]
You are all mix up... lol...
HSA is NOT about a CPU u-arch... at best its about a macro-arch concept, one which is highly flexible... but most of all is about a "PROGRAMMING PARADIGM"...
So according to the names involved, because *they use it*... HSA fits nicely with ARM, x86, MIPS and PowerPC(thought Sony changed, i think its used on some other stuff by some) on the CPU side... TI, ARM, MIPS etc DSPs... all the analogue stuff of ST-Ericsson and MIPS and ARM etc... and its open to many more!...
So catching a few millions here and there, all those guys make many times the size of Intel as example (5x perhaps !?)... Only Samsung itself is bigger than Intel... no matter how much many dogmatic sectarian POV wants to twisted it, it is truth...
Also no matter how hard it takes to many... can be debatable, but highly dependent on how and what you count... from Smarth/Superphones to desktop, by *unit accounts*, the CPU u-arch leader of the client side of computing is ARM not x86... an nothing will prevent with ARMv8 64bit, the spill in force into the traditional Mobile (laptop) side of computing and even some desktop( in this earlier steps)... not even if Intel goes thermonuclear (its too late now).
I think Google saw the light... "renderscript" smells HSA allover some how, and staying more ARM centered and not MIPS or x86... Android will be the only real fight to Microsoft in the client side... though Apple will remain very big, as big as Intel, i think they are "too closed" to ever be the clear dominant force on the client side.
Kroah-Hartman: AF_BUS, D-Bus, and the Linux kernel Posted Feb 14, 2013 20:11 UTC (Thu) by mmarq (guest, #2332) [Link]
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.
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.
|
|||||||||||||