| |||||||||||||
|
| |||||||||||||
Study: Linux nears Windows XP usability (ComputerWorld)Study: Linux nears Windows XP usability (ComputerWorld)Posted Aug 5, 2003 23:37 UTC (Tue) by Peter (guest, #1127)In reply to: Study: Linux nears Windows XP usability (ComputerWorld) by mmarq Parent article: Study: Linux nears Windows XP usability (ComputerWorld)
WHAT IS NEEDED IS A DRIVER MODEL THAT SUPPORTS GENERAL HARDWARE INDUSTRY; AND NOT HIDES BEHIND MODVERSIONS,... I.E. API/ABI FOR HARDWARE. There are several fixed interfaces for hardware. Some have succeeded, some haven't. Some examples of popular hardware with a more or less fixed hardware / software interface:
and a few interface cards whose OS interface was standardised:
So it's not like "hardware with no need for a custom driver" doesn't exist. Au contraire, it's quite common. If you wonder why high-end hardware usually requires custom drivers, ponder it for awhile. It's not like hardware companies enjoy writing drivers - if they could get out of it they probably would. Now, if you actually meant API/ABI FOR DRIVERS rather than API/ABI FOR HARDWARE ... sorry, not gonna happen, google up on UDI, been there done that nobody wanted it except Intel, SCO (yes, that SCO) and david parsons.
(Log in to post comments)
Study: Linux nears Windows XP usability (ComputerWorld) Posted Aug 6, 2003 0:42 UTC (Wed) by mmarq (guest, #2332) [Link] >...sorry, not gonna happen, google up on UDI, been there done that >nobody wanted it except Intel, SCO (yes, that SCO) and david parsonsYou forgot to mention Linus himself, in the beginning,... the problem with UDI was, as you said it, WHO controls it and HOW that control happened. With kobjescts, udev, sysfs and sub systems structures, to wich you can join DKMS and the "hardening patches" that circulated at the feature freeze, you miss very litle to present a consistent Standardised interface allover, in the very footsteps of the USB structure, and why not say it, of I2O that has a split driver model. Better than the M$ unified view, i belive that multiple specialized hardware abstraction layers(API/ABI), is very possible inside Linux/FLOSS in a all open form like LSB,... essencial it only takes to get, ALSA, SCSI, ATAPI, DRM(direct rending), par example," hardware device drivers" out of respective structures and out of the kernel, and interface them by DKMS... This attacks at the very heart of M$ monopoly, wich could release a OS whit BIOS interface a nothing much else, that 6 months later it would have double the hardware support of Linux,... and could be a "BOOM" for all those that are payed and not payed to right drivers for Linux now, because JOB OFFERS MULTIPLY BY HUNDREDS
Study: Linux nears Windows XP usability (ComputerWorld) Posted Aug 6, 2003 17:15 UTC (Wed) by Peter (guest, #1127) [Link] You forgot to mention Linus himself, in the beginning,... the problem with UDI was, as you said it, WHO controls it and HOW that control happened. No, the real problem with UDI was that it was a fixed ABI. From what I remember, Linus has never been in favor of those, UDI or otherwise. If you disagree I'd very much like to see a cite. Basically, nobody in the Linux kernel development camp wants the burden of supporting a fixed ABI. Have you read LWN's 2.5 Driver Porting series? In the last couple of years, all kinds of things have changed that some or all device drivers must adapt to. If Linux had an officially supported layer like UDI, each one of those changes would either (a) not have happened at all, or (b) left behind a UDI compatibility interface. And, over time, those UDI compatibility interfaces would get more and more crufty, and less and less efficient compared to "native" code. There is a reason Linux kernels are something like 1/4 the size of AIX kernels, and I for one would like them to stay that way. There's also the small matter of not wanting to encourage vendors to produce proprietary drivers. There are all kinds of disadvantages to these. Just ask Microsoft if you don't believe me: every time Windows crashes, it's because of a poorly written third-party driver. You laugh, but there's more than a little truth to it. Besides the code quality problems, the simple fact is that vendors who produce binary-only drivers never do so for any respectible subset of architectures Linux supports. Usually it is i386-only, sometimes even narrower: ask any Windows gaming hardware freak about using the latest and greatest hardware with a Cyrix CPU, circa 1998. Ah well, I don't know why I'm even posting. Anyone who argues for a module ABI either does not understand, or does not agree with, such core Linux kernel goals as speed, elegance, portability and not making arbitrary compromises just to support vendors who refuse to participate.
Study: Linux nears Windows XP usability (ComputerWorld) Posted Aug 6, 2003 19:31 UTC (Wed) by mmarq (guest, #2332) [Link] To the heart of the matter.FIXED ABI What is the law that states that an ABI has to stay fixed for ever?...that is the problem with M$, that makes nobody really code to WDM. I "can imagine" an ABI is a burden to maintain and it can limit severely "wilderness" above that layer,... hey but isnt Linux now all about compatibility and stability?,... and isnt that also why there is in kernel modules so that we can have a compartment of diferent codes mechanisms ?... So cant we have, example, ALSA be made a "super-module", that is, a module that has none dependency to other equal "super-module" and at the same time is an ABI to all lower level "AUDIO hardware device drivers", that are outside of kernel and interfacing via DKMS ?? We can have also, a in kernel D-BUS mechanism so that a "AUDIO hardware device driver" for the ALSA API/ABI can communicate whit a "TVcapture hardware device driver for the V4L API/ABI without engaging in strange dependencys!... When ALSA API/ABI CHANGE that DOSENT mean V4L API/ABI HAS TO CHANGE to. I dont know about AIX an it UDI implementation, but i belive the problem is that it try to be an unified vision allover,... but whit diferent ,example, API/ABI for ALSA and V4L most of code remain inside the ALSA or V4l structures, inside the kernel as modules, and as native code as it is possible. For all propose this is a "Multiple" abstration layers "Split" driver model The actual paradigma is to continue, now that 2.6 is about to burst, to try to fix 1 to 2 years old "hardware device drivers" because hardware industry dont disclose technical data for the brand new stuff... and in the end is not hard to imagine, isnt it, a kernel that has equal hardware support than windows but wich sources are about 1 Giga, and toke 4,5 or 6 years to get to the stable version... IT COULD BE THE COLAPSE OF LINUX!
|
|
||||||||||||