Linked by Thom Holwerda on Mon 14th Mar 2011 18:59 UTC
Talk, Rumors, X Versus Y And over the weekend, the saga regarding Canonical, GNOME, and KDE has continued. Lots of comments all over the web, some heated, some well-argued, some wholly indifferent. Most interestingly, Jeff Waugh and Dave Neary have elaborated on GNOME's position after the initial blog posts by Shuttleworth and Seigo, providing a more coherent look at GNOME's side of the story.
Thread beginning with comment 466278
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: F**k this shit!
by oiaohm on Tue 15th Mar 2011 21:37 UTC in reply to "RE[3]: F**k this shit!"
Member since:

Interfaces are not supposed to change rapidly. It's a key software engineering concept ... the interface remains the same the implementation behind it changes.

If the interface does need to change you depreciate the old one and give people time to move over.

The only reason they keep changing it is either poor design or it is a deliberate attempt to force other devs to open source their drivers (if this is true it is another case of "freedom but as we tell you).

Funny Linux did support Unified Unix Driver Standard. No drivers were made for it. It was binding up a kernel mode ABI for no gain. Developers insisted on calling the internal API's they could see not the stable ABI. Was even supported in the 2.6 line. To state what the hardware makers said repeatly for not using the Unified Unix Driver Standard was that the performance hit(less than 0.01 of a percent) was too great.

People can bash Windows all they like but a driver written for Windows XP in 2001 will still work with Windows XP today, the same is true also with Drivers between Solaris Versions.

Pardon. Windows XP drivers written in 2001 still work with Windows XP today. This is freeze kernel progression. Yes that was released is the 2.4 tree that was first released in 2001 that has a stable kernel abi across the 2.4 line has basically no closed source drivers.

Now lets move on to vista. Vista just like Linux kernel 2.6 is pushing lots of drivers to user-space for the same basic reasons no need to tie hands behind back.

Linux dev's really have no excuse.

Problem is people like you are blind. Please note the kernels tagged longterm. They will be API compatible for as long as XP if not longer. Why not ABI. Something interesting. Turns out you must use the same compiler to have ABI. Reason why MS shipped driver development kits containing a different compiler to the normal Windows SDK. If you don't have the same compiler you must wrap the API that does cost performance.

Anyone who builds open solaris themselves with different compilers has also found out that from time to time solaris closed source drivers don't run stable either. So this is a selection between stable and not stable.

Userspace is already wrapped with the syscall framework. Userspace is simpler to provide compatibility libraries. Something people are not aware is some of the old syscalls on linux called from userspace are not processed by the Linux kernel but redirected to userspace libraries. So historic compatibility does not mean kernel bloat.

A userspace driver frameworks its far more stable. Drivers written in them like cups drivers you can pick up cups drivers from 1880~ from a few different unix systems and use them on current Linux by using loaders. 1993 from Linux system and use them as well.

Basically userspace proper solves the kernel to kernel issue. And driver support from hardware makers has been as bad as it always was.

I am sorry but the userspace framework on scale of stable is massive far passing the time frame any Kernel base ABI could offer. Its done in such away they never need to be revised in a way to break backwards compatibility. At worst redirect some syscalls to userspace for userspace handling.

Reply Parent Score: 3

RE[5]: F**k this shit!
by oiaohm on Tue 15th Mar 2011 22:10 in reply to "RE[4]: F**k this shit!"
oiaohm Member since:

Something I have not mentioned so far. Is that the userspace-kernel bridge in Linux can be turned into a kernel ABI with a third party patch. Keeping many advantages

Basically shutup asking for a kernel ABI. Linux developers are providing driver makers with a Highly stable ABI that can be made operate in kernel mode if required. There are not enough drivers to justify Kernel Mode Linux to be integrated mainline.

Reply Parent Score: 3

RE[6]: F**k this shit!
by oiaohm on Tue 15th Mar 2011 23:14 in reply to "RE[5]: F**k this shit!"
oiaohm Member since:

I really should have though all this out.

Other thing about Linux userspace drivers are they are really forever drivers in many ways.

Qemu can wrap a userspace driver to run on basically any cpu type. So maker only gives my 32 bit x86 and I have an arm processor no problems. Yes inside qemu its runs a bit slower but at least the driver will work.

chroots/openvz zones can be created to provide an old system appearance to a userspace driver.

And of course Linux kernel userspace syscall off load. So kernel can drop syscalls and userspace never needs to know since they are now being provided from userspace.

Not something hardware makers particularly like the idea. Once Linux has a open source or userspace driver it has the possibility of having that driver for every CPU and ARCH type linux supports.

Yes Linux design is going after the same thing MS .Net OS dreams have been going after.

Of course being userspace code has not excluded it from being loaded kernel space. And userspace kernel is kernel netural. So what is the problem. Linux had a problem that every other OS has suffered from through time and they design a solution. Most likely the only solution that can proper work in all cases unless you go to something like a java or .net OS core.

Of course there is a disadvantage of userspace drivers. No nasty stunts can be done to stop reverse engineering.

Reply Parent Score: 2

RE[5]: F**k this shit!
by nt_jerkface on Tue 15th Mar 2011 23:16 in reply to "RE[4]: F**k this shit!"
nt_jerkface Member since:

A userspace driver frameworks its far more stable.

So all drivers are better off in userspace?

Reply Parent Score: 2

RE[6]: F**k this shit!
by oiaohm on Wed 16th Mar 2011 03:38 in reply to "RE[5]: F**k this shit!"
oiaohm Member since:

"A userspace driver frameworks its far more stable.

So all drivers are better off in userspace?

nt_jerkface good question.

Some drivers at moment will perform badly at the moment done userspace. Mostly due to context switches. But if there was enough demand merging of kernel mode linux would become important. That basically fixes those performance issues completely.

There are a small number like memory management cpu initialization, video card first initialization that simple cannot be done as userspace basically the ones that a base kernel image of linux will not run without. Yes they are still drivers even that they are in the single file kernel blob.

All the module loadable drivers other than a very small percentage(The ones that have todo operations from ring 0 like virtualisation ie ring 0 is not on offer to user-space for very good reasons) would be in most cases be better off done using the userspace api's.

In fact some drivers in the Linux kernel are being tagged to be ported to the userspace api simply to get rid of them out of kernel space.

Most important thing about being done off the userspace api is that if you are having kernel crashes and you suspect a driver if they are are done in the userspace api you could basically switch to a microkernel model. Run the driver in userspace. Application or driver crashing in userspace normally does not equal complete system stop so making it a little simpler to find that one suspect driver.

So why are they not. fuse cuse and buse are the last 8 years. So drivers prior to that were done in kernel space because there really was no other way that would work.

Next is kernel space does have some advantages. Those advantages do explain why the API in there is unstable.

Main reason for using the kernel space over userspace is speed. For the speed there is a price Kernel space driver can bring the system to a grinding halt with a minor error. No such thing as a free lunch.

Due to the fact that kernel space is for speed. Any design error has to be removable at any time. So the API in kernel space are in flux. BKL was a classic example. Good idea a the time. Many years latter it had to go. Stable Kernel ABI based on internal kernel structs would have prevented that removal as fast as it was. Why you are using Kernel mode explains why Linux kernel mode is in flux.

So the deal you choose between with user-space and kernel mode basically is.

Userspace highly stable, issueless with future versions of kernel, unless something really rare happens never crashes you computer(ie driver might get restarted) but slightly slower depending on the device this may even be undetectable, can be cross platform and cross arch at basically the same speed.

Kernel Space. Fast, Can crash your computer with even the smallest error, Will have issues with future versions of kernel at some point due to ABI/API/Locking changes, normally not cross arch or cross platform if cross arch or cross platform normally as slow as the userspace api used from kernel mode or worse slower than using the userspace interfaces in the first place(what is the point).

Note those deals apply to Windows Linux and Solaris to different amounts. Linux with its faster kernel major version cycles shows up will have issues with future versions of kernel more often. Lot of people remember getting Windows 7 and XP before it and finding a stack of devices no longer worked safely ie add the driver upset computer.

Due the risks in kernel space is why Linux people want the source code in there so it can be fully audited. Basically do you like the Blue/Red screen of death or Linux kernel panic. If no you really should agree with what the Linux developers want. Even MS is giving up on the idea. Most of the gains of kernel space are not with the loss in stability.

The way I put is that closed source driver makers wanting to use kernel space are like carrying possible drug using gear into an airport and trying to refuse having you ass and other private areas inspected. Basically inspection should be expected.

Do I expect driver makers or any poor person who has to be inspected at a airport to be happy about it. No I don't that would be asking too much. But they should be understanding why they got what they did.

Reply Parent Score: 2