| |||||||||||||
|
| |||||||||||||
A Sun engineer on LinuxA Sun engineer on LinuxPosted Sep 23, 2004 18:45 UTC (Thu) by mmarq (guest, #2332)In reply to: A Sun engineer on Linux by Duncan Parent article: A Sun engineer on Linux
" Rightly or wrongly, the kernel
Agree as a principle that is coherent.
"That's a great position for the kernel hackers to take, and one I
That i dont agree with the spirit of the sentence. The problem *is not* or *should not* be the likes of SUN, but thousands and thounsands of advanced users and IT professionals that are the 'strongest' Linux adopters (not the six pack commom joe users and not the somehow *affraid* big entreprises and goverment institutions),... and that 'strongest' Linux adopters have the power to completely change the IT landscape... if only given the chance...
IMO what Open Source needs in that department, is again standards, not Linux standards but a Open Source Driver Model from OpenDarwin to BSDs to Linux and possibily OpenSolaris,... let the *better* kernel win !...
In my low technical ability of this matters, i belive, that that could be achieved with a message passing communication layer, forming a ´split´ Driver Model, similar in spirit to I2O, and not requiring no one to bend over to any ABI compatibility...
Better for what i can understand of D-BUS: http://www-106.ibm.com/developerworks/linux/library/l-dbu...
...well just a good idea anyway... at least an idea, IMO, that has the power to percipitate the entire Hardware Industry to jump head first into the Open Source bandwagon.
(Log in to post comments)
A Sun engineer on Linux Posted Sep 23, 2004 21:30 UTC (Thu) by khim (subscriber, #9252) [Link] In my low technical ability of this matters, i belive, that that could be achieved with a message passing communication layer, forming a ´split´ Driver Model, similar in spirit to I2O, and not requiring no one to bend over to any ABI compatibility... Hmm... Possible ? Yes. Feasible ? Hardly. For example if you are using right kind of hardware then data can be transferred from disc (via DMA) straight to network card buffer - without processor help and in some cases even without main RAM involved. It's quite easy to do with linux kernel (if hardware is capable): drivers know enough about kernel internals to easily shuffle data around in such a way. It's very hard to develop something like this with "split drivers". Proprietary drivers have nasty tendency to become broken and obsolete long before hardware becomes unusable. Windows suffers from this horrible. "Oh, your three year old winprinter have drivers for Windows98 but not for WindowsXP? Sorry - we can not do anything with it. You USB gadget works fine with Windows2000 but will crash WindowsXP? Try to ask manufacturer and pray...". And this is Windows! With mighty Microsoft behind it! You can be very sure binary drivers for "split driver model" will have a lot of kludges, will break constantly (it's one thing to write specifications for "correct split drivrs" and it's quite another thing to make vendors do drivers really compatible with abstract specifications and not with real Linux 2.6.8.1 or FreeBSD 5.2) and so on. Just like most binary-only Linux drivers today. No, it does not worth it. Too many problems, too little gain. Solaris x86 does support far less hardware then Linux after all.
Why a split model makes sense Posted Sep 23, 2004 22:58 UTC (Thu) by mmarq (guest, #2332) [Link] " be transferred from disc (via DMA) straight to network card buffer - without processor help and in some cases even without main RAM involved...... drivers know enough about kernel internals to easily shuffle data around in such a way. It's very hard to develop something like this with "split drivers". "
Processores, memory and disk always had plenty of good support in many Open Source kernels, *you simple dont have to put everything under a 'split model'*.
By the way, it is very hard to me to discuss deep technical details of kernels, but never the less i suspect that with my example about D-BUS extension it wouldn't be that hard,...
" Proprietary drivers have nasty tendency to become broken and obsolete long before hardware becomes unusable... "
That is the main reason because a split model, not ABI compliant, makes all the sense... nasty or not the software can be mended, but the hardware can only be changed, even inside a family... as simple as that.
"You can be very sure binary drivers for "split driver model" will have a lot of kludges,... "
True. But worst than kludges is no support at all... and you can always harden the kernel, like in patches that circulated before 2.6.0, i belive, and that were supposed to kick out from running any kernel module that breaks... and join to that the possibility of load the tiny 'split' extension portion, in RING 0 or RING 1 of the processor, far way from userland where Windows drivers get massacreded by all sort of "your computer is mine" software and other malware.
And if a 'split model', light on overhead, and with little "intrusivity" because it dosent need an ABI compliance, is negociated trough out the all Open Source landscape, i belive, the hardware industry will jump right on because the "same" driver will be possible to run from OpenDarwin(Apple Iron) to the BSDs to Linux and OpenSolaris... then we get to know which kernel is the best, and not having people talk the talk in blogs, and them having excuses for not being able to walk the walk.
Why a split model makes sense Posted Sep 24, 2004 22:23 UTC (Fri) by khim (subscriber, #9252) [Link] True. But worst than kludges is no support at all... Not true. It's much better to know that this or that piece of hardware is "no-go" then to buy RAID-controller with Penguin on sticker and only crappy driver for Linux 2.4.10 or somwathing. and you can always harden the kernel, like in patches that circulated before 2.6.0, i belive, and that were supposed to kick out from running any kernel module that breaks... And if module does not work and is kicked from kernel this helps me exactly how ? I still can not use the thing. If you can use driver for USB-IrDA dongle and it works just fine till you'll try to use it to connect to some device via IrDA (real-life example from W2K=>WXP transition) - how it's usefull for you ? and join to that the possibility of load the tiny 'split' extension portion, in RING 0 or RING 1 of the processor, far way from userland where Windows drivers get massacreded by all sort of "your computer is mine" software and other malware. Windows drivers were in userspace long-long ago. With NT they always were protected from userspace. It does not help with subtle API changes at all. I see how "good" it works for Windows and Solaris. Not very good at all: drivers from third-party providers are often break after major upgrade despite "commitment to binary compatibility". Sometimes installation of some Service Pack is enough.
Why a split model makes sense Posted Sep 25, 2004 11:07 UTC (Sat) by nix (subscriber, #2304) [Link] You think that's bad? Within the last year, I've bought NICs with a penguin on the sticker... and a driver for Linux 2.0.28!
(Naturally, 2.4.x supported it natively. 2.2 didn't, so what they thought they were playing at with a driver that antique I don't know; it clearly wasn't support for pre-native-support kernels that they were thinking of.)
A Sun engineer on Linux Posted Sep 23, 2004 22:19 UTC (Thu) by Duncan (guest, #6647) [Link] > IMO what Open Source needs [is standards,> not just Linux,] but a Open Source Driver > Model from OpenDarwin to BSDs to Linux > and possibily OpenSolaris,... Neat idea. To bad it can't work, for both technical and political reasons. Technical, because Linux tends toward a monolithic kernel model where even if there are modules, once they are loaded into the kernel, they become /part/ of the kernel (thus one of the objections to proprietaryware modules and why the kernel hackers insist that the kernel is tainted when a closed source module is loaded, that could do virtually /anything/), while the BSDs AFAIK tend toward a far more "microkernel" design where the drivers are /not/ part of the "microkernel" but operate at a lower privilage level either as "userland" code or just above it, but below the level of the "microkernel" code. (Vastly simplifying reality, a very general statement of the relative benefits of each model would be that microkernels are less complex and easier to stabilize, since the amount of code operating with maximum privs is relatively small, while monolithic kernels tend to be higher performing, and are either less stable or take far more effort to make stable. In reality, however, neither model tends to be used in pure form in modern operating systems, thus my use of the qualifier "tend toward" in the above description.) Political, for the same reason Linux and the GPL haven't merged with the BSDs already, at the macro/legal level, and there are multiple distributions and multiple BSD variants at the micro/interpersonal level. At the macro level, there's a split between the philosophies of those that believe code isn't truly free unless it is free to be used even in proprietaryware, and those who simply aren't even interested in contributing if others can take the contributed code and close it up, without returning improvements to the community from which the code originated, while at the same time publicly distributing the binaries (as Apple has done with the many proprietary improvements it made to the BSD base it used for OSX). Keep in mind that many developers are contributing in their free time, while others work for companies and can contribute code /only/ under the condition that it can't be made proprietary and potentially used by a company competitor. For the former, it may simply not be worth the bother if others can take the code without paying /something/ for it (in either cash for use or code improvements in return), while for the latter, they wouldn't even have the /choice/ of contributing if it could be made proprietary. This contrasts, as I said, with those who wish that their code be as widely used as possible, even becoming a standard, even where that means use in proprietaryware (as MS used BSD code to implement its original TCP/IP stack, as well as the previous Apple/OSX example). These camps will never be fully reconciled, but fortunately, that's fine, because there's room for both in open source. Likewise, at the micro level, interpersonal politics is part of the reason we have four BSD variants (Open, Net, Free, Dragonfly) and all the Linux distributions. Were there not serious personal disagreements, quite apart from philosophical ones, we'd have fewer splits there, as well. However, again, open source has proven that it's a "big tent", big enough to let folks that can't get along with each other work in different portions of the community, while remaining /in/ the community. Duncan
A Sun engineer on Linux Posted Sep 24, 2004 1:10 UTC (Fri) by mmarq (guest, #2332) [Link] " Neat idea. To bad it can't work, for both technical and politicalreasons. "
No??... but it has already worked when a young computer engineer decided to make something cool over the net with 'friends'...
Who would had thought, in the middle 90's, that the Linux kernel ends up in the position that it is now ?... the key to the impossible seems to be persistence and looking out from the side way problems... if they had worried about political, social, and many of the technical hurdles from the very begining we wouldn't be discussing this now.
There aren't any political problems really, only those of more egoistic views against less egoistic or altruistic views...
Again, if blessed by the simplicity of an unworied begining, if the many 'anonymous' friends over the Net dindn't work out their differencys, we wouldn't have Linux.
Linux dont have to merge to the point of losing personality to achieve consensus, neither does the BSDs or OpenDarwin or OpenSolaris. Consensus is exactly the contrary of self destruction or of letting others destroy you. And consensus is the bases of powerfull standards. Microsoft only is what it is today because, an almost family company, had the vision to profit from the Unix wars, and impose a standard, that no *SINGLE* one was able to defeat, and so impose a dominium to the much larger confliting Unix parties.
The technical hurdles derive directly from above. There isn't the problem of different approaches with the processor ring privileges... that is a false question because almost exactly the same code can be made to work in kernelmode (ring 0), or ring 1 or in userland (ring 3). There was a web server inside Linux kernel once... Different approaches always existed and always will exist, the contrary seems what Microsoft is trying to marketing brainwash people with. Technical frontiers can be layed out in consensus, and defended by all in consensus, and that include a Driver Model that everybody in Open Source, including Microsoft if they will to Open more, can profit from... that is not to much far fetched... it only fail for sure if the Open Source community dosent try... and after all the main propose of a kernel is to make all the hardware to function !!
A Sun engineer on Linux Posted Sep 24, 2004 8:22 UTC (Fri) by khim (subscriber, #9252) [Link] As I've said already technical problems do exist but is solveable. Political problem is other story: when Linus first hacked kernel he did it to make "GNU on PC" possible. Here and now it was the only thing he cared about. Everything else come afterwards. What exactly will split driver model bring to the table ? Here and now, not in some distant future ? A lot of headache for kernel maintainers and ability to do... what exactly ? When you are trying to solve technical problem you need technical solution. When you are trying to solve political problem you can not use technical solution. And since "split driver model" is big PITA for kernel developers without any immediate benefits it becomes mostly political problem: if you'll convince someone to do so you'll do it for political merits, not for technical ones. And it's very hard sell in free software world... If you'll recal there is driver for all disk drivers: it's called BIOS. It's exactly "split model" you proposed. Yet there are no contemporary OSes based on BIOS acess to disks. Why is it ? Think before answer.
A Sun engineer on Linux Posted Sep 24, 2004 21:55 UTC (Fri) by mmarq (guest, #2332) [Link] " As I've said already technical problems do exist but is solveable "
Then the rest of your argumentation is almost all political in nature. Sure there isn't an easy and perfect solution that does not give a lot of work and trouble... but that was always the tryumph of Open Source... it didn't made stops because of the hurdles that scared so much 'close' developed projects.
" If you'll recal there is driver for all disk drivers: it's called BIOS. It's exactly "split model" you proposed. Yet there are no contemporary OSes based on BIOS acess to disks. Why is it ? Think before answer. "
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... 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* ... IMO is a SMALL PITA, that dont invalitate the pressure for the hardware industry to open more in the technical documentation department, which inspite of how much we'd love(including me) that could be much better, it simply dont depend on the community, and solely depend on the *proprietary* powers that some part of this community seems to fight so furiously... it is simple an arround never ending race!!... and that is what is undoubtly a *ENOURMOUS PITA*.
A Sun engineer on Linux Posted Sep 24, 2004 22:35 UTC (Fri) by khim (subscriber, #9252) [Link] 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.
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*.
A Sun engineer on Linux Posted Sep 25, 2004 18:39 UTC (Sat) by vonbrand (subscriber, #4458) [Link] IMO what Open Source needs in that department, is again standards, not Linux standards but a Open Source Driver Model from OpenDarwin to BSDs to Linux and possibily OpenSolaris,... let the *better* kernel win !... Nice sentiment, but that won't fly. Just look at the massive changes in the driver model in Linux from 2.0, 2.2, 2.4, to 2.6. They weren't gratuitous, there are sound reasons behind the changes. And surely while there is a healthy dose of "Oops, screwed that one up; let's try and make it right this time around" (BTW, the people designing this changing interface did look at the "unchanging interfaces" used elsewhere), at least some of it has been predicated by external changes (hotplugging all over the place just wasn't even a pipe dream when Solaris started some 10 years back, much faster CPUs, hyperthreading, large memories, NUMA, you name it, have changed the demands on the driver model dramatically). In the end, it is the driver model that makes up a large part of the OS. By mandating an unchanging driver interface, Sun is painting themselves into a corner, IMHO. Sure, they can continue dressing up their particular corner with their own high-end iron, but even with very large margins there the PC price/performance will eat them alive over short or long. It killed off DEC and a lot of other midi-frame vendors, and even mainframe vendors like IBM are looking elsewhere.
A Sun engineer on Linux Posted Sep 26, 2004 0:57 UTC (Sun) by mmarq (guest, #2332) [Link] Yes, you might be right in the sense that the horizont of that sentiment may lay far away in a distance galaxy...
Perhaps a better aproach, could be, i belive:- Gentleman, if your BSDs, OpenDarwin, OpenSolaris(??) want to profit from the far superior hardware support that Linux has(A FEW YEARS FROM NOW), you could work to help OSDL to create separated trees of your kernels that implement for your kernels the technical superior features relative to device driver support( open to discussion), and that way create an Open Source Device Driver Model, that all kernel and Unix flavours could profit in the sense that a "low level" kernel module could be used *UNCHANGED* across kernels.
That is, all kernels "will" implement a form of :
The latency of such a 'Declaration' could be enourmous, yes,... worst it could inflate the personality not of some kernels, but of some kernel developers beyond the explosion point,... but persistence would win,... there were already mingling code between Linux and BSDs far before,.. better 'they' are using ALSA(FreBSD i belive), as well as KDE and GNOME.
All of a sudden, we are actualy talking of code and documented mechanisms that exist already in large proportion...
The pipe dream then dosent seem of a far galaxy anymore...
A Sun engineer on Linux Posted Sep 26, 2004 1:33 UTC (Sun) by mmarq (guest, #2332) [Link] hmmm... may be i'm wrong,... but an IPC mechanism for drivers (D-BUS based or some other form talked above) could be the help to implement proper HOT-Pluggin across the board,... as well as suspend to disk,... as well as proper power saving modes to all categorys of hardware that compose a computer...
Although i not the right person to discuss such details, and i'm not trying to sell nothing to nobody.
By the way,... IMO was closed platforms not exactly hardware/software, but *MOSTLY HARWARE* for in house comsuption only, that not only killed DELL, but almost killed Apple, until they changed to PCI and ATA/SATA, and also kicked the well of P4 sells when Intel insisted on RAMBUS,... and is definitely pushing SUN into the edge... So having *no form at all what so ever or not* of a standard for hardware device drivers had nothing to do with those mysfortunes... Just look at Microsoft with their WinHEC specifications,... hein!??
|
|
||||||||||||