| |||||||||||||
|
| |||||||||||||
A Sun engineer on LinuxA Sun engineer on LinuxPosted Sep 24, 2004 22:35 UTC (Fri) by khim (subscriber, #9252)In reply to: A Sun engineer on Linux by mmarq Parent article: A Sun engineer on Linux
Geez... sorry about my mistake!... but are disk drives that important ?... IMO they are quite irrelevant, as irrelevant are other subsystems that have plenty of good enough support... Since a lot of high-end controllers DO NOT have good support they are relevant. the problem are subsystems that dont have good support and as i said before * you simple dont have do change everything to make it 'split' complaint* ... That's exactly problem with "split drivers": you must literally redesign everything to make idea feasible. Otherwise you'll have the same problem as BIOS have with hard discs: yes, it works, but it's so slow it's totally unusable. If some piece of hardware is so slow that speed is not an issue you can just move everything to userspace and avoid drivers in kernel altogethers. Printer support is implemented this way and it works great.
(Log in to post comments)
A Sun engineer on Linux Posted Sep 25, 2004 1:04 UTC (Sat) by mmarq (guest, #2332) [Link] " That's exactly problem with "split drivers": you must literally redesign everything to make idea feasible...... If some piece of hardware is so slow that speed is not an issue you can just move everything to userspace and avoid drivers in kernel altogethers "
Sound a little contraditory... you would need some interface to the kernel anyway, and userland to kernel is somehow 'split' anyway... pardon my hardness of speech... and some ignorance in the details that i might show...
But the big question is *Everything ?*... well is just a big ??... what particular *existing* implementation or patch are we discussing about ???...
I2O ?,... from what i read and understood it seems really a dramatic change to go beyond what is already in kernel: (links in URL)
But is that all there is ?
An idea was laying arround from reading:
The problem solved by the systemwide or communication-with-the-OS case is explained well by the following text from the Linux Hotplug project:
A gap in current Linux support is that policies with any sort of dynamic "interact with user" component aren't currently supported. For example, that's often needed the first time a network adapter or printer is connected, and to determine appropriate places to mount disk drives. It would seem that such actions could be supported for any case where a responsible human can be identified: single user workstations, or any system which is remotely administered.
This is a classic "remote sysadmin" problem, where in this case hotplugging needs to deliver an event from one security domain (operating system kernel, in this case) to another (desktop for logged-in user, or remote sysadmin). Any effective response must go the other way: the remote domain taking some action that lets the kernel expose the desired device capabilities. (The action can often be taken asynchronously, for example letting new hardware be idle until a meeting finishes.) At this writing, Linux doesn't have widely adopted solutions to such problems. However, the new D-Bus work may begin to solve that problem.
And:
* Binary protocol designed to be used asynchronously (similar in spirit to the X Window System protocol).
* Stateful, reliable connections held open over time.
* The message bus is a daemon, not a "swarm" or distributed architecture.
* Semantics are similar to the existing DCOP system, allowing KDE to adopt it more easily.
Better, even if i degress above, never the less it seems the answer to the prayers of technical problems( not political) raised here:
And since it is a messaging system that dosent have to bend any ABI complaiance, then it dosent have to be in conflit with what is said here:
And since it is *so* low footprint, to the point of herding somewhere of putting 'libdbus' in kernel space anyway, how much more intrusive it could be from an average structural change in kernel anyway ??, if that "small" structural change has the propose of only load *tiny* module extension to the Linux drivers already present in kernel, in a similar way to the *single* NVIDEA driver that loads *tiny extensions* relative to the particular Graphic Board present.
Ok, OK,... it means to change all the actual hardware device drivers that this thing touch... but according to a real expert;... here again :
Well why not keep that way where the support is good, and change to new structures where the support is bad ?... the loss and the work of that change dosent seem much.
Rest my case.
A Sun engineer on Linux Posted Sep 26, 2004 9:13 UTC (Sun) by khim (subscriber, #9252) [Link] ound a little contraditory... you would need some interface to the kernel anyway, and userland to kernel is somehow 'split' anyway... pardon my hardness of speech... and some ignorance in the details that i might show... 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. When driver can not be easily pulled in userspace you more often then not can not create "split drivers with stable API" as well. Where's contradiction ? And since it is *so* low footprint, to the point of herding somewhere of putting 'libdbus' in kernel space anyway, how much more intrusive it could be from an average structural change in kernel anyway ?? 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. if that "small" structural change has the propose of only load *tiny* module extension to the Linux drivers already present in kernel, in a similar way to the *single* NVIDEA driver that loads *tiny extensions* relative to the particular Graphic Board present. Have you looked at NVIDIA driver ? This is good example why your proposal does not work without huge changes in kernel internals. It's huge beast and it does not play well across quite wast number of kernel changes - you need to wait for nvidia to fix binary part of driver. The only reason why it's usable at all is nvidia's constant efforts to make it compatible with new kernels. You can not expect this from average manufacturer. 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. Well why not keep that way where the support is good, and change to new structures where the support is bad ?... ...and have bad support for these type of hardware forever ? Thnx, but no thnx. the loss and the work of that change dosent seem much... The work is enormous: 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. It's huge PITA to keep userland interface frozen (it's frequent topic of debate on lkml "how can we change this or that and still keep userspace from noticing anything?") - and you want new one, equal in difficulty just for few crappy drivers ? Thnx, but no thnx.
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...!!?
"...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.
A Sun engineer on Linux 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*.
|
|
||||||||||||