A Sun engineer on Linux

Posted Sep 26, 2004 18:03 UTC (Sun) by mmarq (guest, #2332) [Link]

" Huh. It's simple: in cases where you can safely make split-driver (i.e. where driver can be pushed far away from kernel to form a stable API) you can almost as easily pull it in userspace completely and avoid all this talks "

You are reminding me that the Linux USB infrastructure is already completly 'split' in nature, as is 1394, as is ALSA... 'splitness' is not a marketing buzzword and dont seem something that the Linux kernel and other kernels are complete strangers to... the simple idea of modularity implyes a certain kind of splitness anyway.

So 'APIs belonging to a new 'split' framework can evolve as the rest of any other API, as long it keeps speaking the protocol... like in Ethernet, where we have so many different implementations, and in a state of flux like in Linux, with different API particularitys, but that dosent stop a Linux box to talk to a Windows box or to a BSD box... and in that sense you can have all those 'split' *extension modules* in userspace instead of kernelspace as you suggest, and still make them talk through the same IPC protocol anyway. The economy that i'm suggesting with a new, "advanced split framework", is that the Linux kernel could have changed as it did, as well as the APIs of that 'split' infrastructure inside of it, but that "tiny" *module extension* could have remained the same(in cases where the NIC is the same)... if that *module extension* were good enough and stable... or could have changed also if it were not... it will not be dead ends, because they are talking through an IPC based protocol that is not ABI complaint, being those *module extensions* in kernel or userland... and all this makes perfect sense to me, and to the majority of people, i belive, because the Linux Ethernet implementation have changed along this few years, with inumerous, non functional or non debugging changes to the driver i use, but i'm still using the same NIC.(when, "IF" you'll approach the million drivers inside, with the ever increasing in complexity nature of hardware, linux then would be unmaintainable:-Thnx, but no thnx.)

And since D-BUS is stated to be *very low* in overhead, it seems a good candidate. And since that 'split framework' subsystem is independent of any other subsystem, you would only have to make changes, for the 'new split framework' model, to those subsystems that youd like, arbitrarily... it dosent have to be the network subsystem. I belive this is perfectly doable and sensible.

"DBUS only proposes to add stable interface to userspace for some non-time-critical operations. It does not change anything about kernel iteraction with already loaded drivers."

That is why i talked about an extension(vaporware yet!?)... and an extension with the purpose of only thouch subsystems, in a first fase perhaps, where the support is bad, or where the subsystems have already a clear splitness, what makes them perfect candidates, like the mentined USB,1394,ALSA... and that is achievable because that *D-BUS extended framework* infrastructure is independent of any other subsystems that you might put into the kernel, and is a stateful and asynchronous protocol. It could be laying there in kernel doing nothing, just for the fun, if you wich. We already have there a moribund I2O subsystem that nobody or very very few people seem to use, anyway.

"Have you looked at NVIDIA driver ? "

Unfortunatly the nvidea driver i use, is a user space module, that is loaded by a new NVIDEA interface added to the kernel, different from the interface already there and different from any other interfaces from other Graphics Boards suppliers, namely ATI, which in his turn is also different from the interface already in kernel...!!?
That is the perfect example of what cannot go on,... is the worst kind of fragmentation,... it is a form of trying lock-ins, and makes Linux very susceptible to commercial wars.

"...and have bad support for these type of hardware forever ?"

??!!... should i comment political, or what...??... the 'advanced split framework' can suit 'Open' perhaps better than 'Proprietary', because it could make it much more easy to compile from source, without modversions and without some makefile magics sometimes needed, when only 1 module is needed to be changed.

"you'll be forced then to keep this frozen subsystem in working state - just like you keep kernel interface to userland frozen, akin to what nvidia does for "glue level" of nvidia driver"

Well what i suggested is a IPC based protocol, i almost 100% certain that it dosent imply, not even near, that kind of frozeness that you mention.

Posted Sep 26, 2004 19:55 UTC (Sun) by mmarq (guest, #2332) [Link]

On better look...

" Plus I've never seen new nvidia subriver for new piece of hardware compatible with old piece of main driver - so I can not see what are you talking about. "

Geez!... that wouldn't be asking for too much ??... but the answer might be yes anyway, if that new piece is from a family already present, and dosent need diferrent support of what is already present in the main driver... or...

... does that mean you know better... because you had the chance to look at the code of their unified driver!??... or what??(nvidea buddys ?)...

... but better than Linux kernel is exactly that they *appear* to be able to had support for a new chipset family, only with "some" changes to the main driver, and whitout having to change even a single line of code to the *majority* of the drivers modules(if we can call them that) *already present*.

...it was the example i gived, but it dosent *seem* not even near, an *ALL GO* for splitness much more than the Loadable kernel Module... its a commercial strategy,... defensive in nature because it loads an entire Nvidea environment, that prevents a correct comparison with offers from the competition,... and offensive in nature because if that environment happens to be better than the competition, it will create lock-ins.