Linux Kernel To Have Stable Userspace Drive

liquidat writes "Linus Torvalds has included patches into the mainline tree which implement a stable userspace driver API into the Linux kernel. The stable driver API was already announced a year ago by Greg Kroah-Hartman. The last patch to Linus' tree included the new API elements. The idea is to make life easier for driver developers: 'This interface allows the ability to write the majority of a driver in userspace with only a very small shell of a driver in the kernel itself. It uses a char device and sysfs to interact with a userspace process to process interrupts and control memory accesses.'"

Comments

Better drivers and more of them

[Billly Gates]

A stable kernel api for drivers is what linux needs as proprietary driver writers make poor quality and buggy implementations. While this is not a kernel one its a good compromise as proprietary drivers are here to stay as much as it would be great if we had free gnu ones inside the kernel.

I wonder if it would be easy to port it to windows and macosx? IT would be cool for hardware makers to have a driver that works with all operating systems with minimal effort in porting. Costs are one of the issues besides the difficulty in porting windows drivers to linux which many makers do not bother doing.

Re:Better drivers and more of them

[Ice.Saoshyant]

Windows' drivers are on userspace. That doesn't make it any easier to port them to Linux. Drivers are very OS-centric; they tell the OS how to interact with the hardware and, of course, Linux and Windows have very different ways of interacting with hardware.

Re:Better drivers and more of them

[whomeyup]

There's a userspace drive framework on Windows, but the vast majority of Windows drivers reside entirely in kernelspace.

Re:Better drivers and more of them

[ozmanjusri]

Drivers are very OS-centric; they tell the OS how to interact with the hardware and, of course, Linux and Windows have very different ways of interacting with hardware.

That still doesn't preclude universal drivers. In fact, Linux can already use some Windows drivers via ndiswrapper.

I agree with the GP poster, it would be a wonderful thing for computer users, but suspect Microsoft would put VERY heavy pressure on any hardware maker who looked like participating in that sort of development.

Re:Better drivers and more of them

[chromatic]

Costs are one of the issues besides the difficulty in porting windows drivers to linux which many makers do not bother doing.

If only there were some magical pool of experienced labor just waiting to write and maintain, in perpetuity, Linux drivers for any manufacturer of any hardware....

Re:Better drivers and more of them

[sumdumass]

The point wasn't really that the driver would be portable now but could they be in the future. It is just that they would be more palatable for the manufacturers who wants the stuff to work without open sourcing everything because of some fear or whatever and think that one effort would be a benefit to them.

It also allows the ability for the API calls to mimic some of the windows interface calls which while different in implementation could lessen the learning curve for a company new to the linux game. It could be that with a small kernel driver to compliment or supplement the APIs, the windows driver could work efficiently in linux.

Although I disagree with the GP sentiment that user space drivers is somewhat less valuable then kernel space drivers, It doesn't make a difference where the driver is implemented as long as the same things are achieved at the same efficiency. It doesn't take any longer for something specific like this to happen at user space then it would under Kernel space if everything is working correctly. You can have the same amount of speed and reliability in both. And as far as the user is concerned, a lot of things are transparent as to where they are located. However, there is a small subset of things that might require Kernel space implementations. I'm just not sure how that differs from todays implementations.

Re:Better drivers and more of them

[kasperd]

I wonder if it would be easy to port it to windows and macosx? IT would be cool for hardware makers to have a driver that works with all operating systems with minimal effort in porting. Costs are one of the issues besides the difficulty in porting windows drivers to linux which many makers do not bother doing.

It might help a bit. But for a lot of hardware they are not going to be shipping this driver for Windows. If possible they are going to ship a user mode driver to be able to claim that their hardware works with "every" operating system. And they are going to be shipping a real Windows driver. And "everybody" is going to say Linux performance sucks because Linux only have user mode drivers, where Windows have real kernel drivers. (Of course the same people are going to blame Microsoft for every time the driver crash their system).

Of course for some hardware performance is not all that important. As long as the driver will be locked in memory, it won't matter if something like a keyboard driver was done in user mode. Hell, in recent years lots of hardware have been designed that will require the driver to spend loads of CPU time, because that could shave a few cents of the hardware cost. Such hardware would be slow on any operating system, kernel driver or not.

Re:Better drivers and more of them

[Peaker]

I, for one, am glad that proprietary drivers are so poor, because it encourages free drivers to be written instead.

These are not only free-er, but usually of better quality too.

Re:Better drivers and more of them

[heinousjay]

And all they would ask is permanent access to the intellectual property of the company. A pittance indeed for a technology company.

Re:Better drivers and more of them

[howlingmadhowie]

exactly. the fact that there aren't linux drivers for every piece of hardware does reflect very poorly on the hardware manufacturers. the kernel developers called their bluff on this a while back (as you allude to). it soon became clear that "we only have so many programmers working for us" and "why should we support a niche operating system?" are totally bogus reasons used to spread fud. what the real reason is, i can only speculate, but i'd tip on it having something to do with microsoft.

Re:Better drivers and more of them

[howlingmadhowie]

no one wants the driver. what the developers what is documentation for the connectors to the motherboard. surely this should be a legal requirement for the manufacturer anyway. i would regard it as the minimal acceptable documentation for the product. it is, after all, my computer the hardware will be attached to.

i would personally like to see all pieces of hardware sold with schematics for the hardware. with other products, like cars, this is trivial anyway--anybody can open up the car and see what bit goes where. with computer hardware, because of things like microcode, this is impossible.

and as for intellectual property. what strikes me is how this phrase is always used to protect the financial interests of a company against the greater good for society and the individual. if someone would instead be honest and say "companies are allowed to require society to install software (which does what exactly?) and use a particular operating system if the user wants to use their hardware, so ensuring (at the least) that the product will soon be unusable" then i'd have less against the people who champion this position

in the best case, this is built-in obsolescence. one thing i find repugnant is the attitude that it is morally okay to force society into this position.

Re:Better drivers and more of them

[heinousjay]

I'm sorry, force society into what position? To using a product? I see no force anywhere. Technology is a luxury item not necessary in any way to survive.

Of course, it's awfully easy to take the position that other people's shit should be taken away from the them and handed to me. I just see something morally repugnant about that.

Re:Better drivers and more of them

[Solra Bizna]

I, for one, am glad that proprietary drivers are so poor, because it encourages free drivers to be written instead.

These are not only free-er, but usually of better quality too.

I'm still waiting for a Free 3D driver for my Radeon 9800 Pro Mac Edition. (Not for much longer, though, since I'm moving to an all-OSX setup on my next computer...)

-:sigma.SB

P.S. no, the R3xx DRI code in the Xorg tree did not work. Not even accelerated 2D.

Re:Better drivers and more of them

[Maniac-X]

It may have something to do with Microshaft, but then again, it could also simply be an aversion to experiment with something that has the possibility of decreasing their overall revenue. I think they're mainly just trying to be as efficient at money-grubbing as possible, at least in some cases.

Re:Better drivers and more of them

[sethawoolley]

Frankly, I'm just not buying this excuse.

If they have to hide the information in their interfaces between their hardware and software drivers, then their IP in their hardware or their software isn't all that great.

I don't even care about their software drivers. Just give me access to their framebuffer and/or how to drive the hardware and I'll buy your hardware.

Don't and I won't. That's a market reality.

Re:Better drivers and more of them

[howlingmadhowie]

for a start, it's not "other people's", it belongs to a company.

secondly, there already exists a framework to protect intellectual property. we call it the law.

thirdly, i don't see how anything is being taken away from the company.

i suppose what i'm really against is technology being used to restrict the freedoms and capabilities of the individual when the safety of the individual is not at stake. by all means the law can be used, but the law always has to consider the freedom of the individual first.

Re:Better drivers and more of them

[sethawoolley]

"Of course, it's awfully easy to take the position that other people's shit should be taken away from the them and handed to me. I just see something morally repugnant about that."

You don't want to clean up other people's shit? I can't disagree with you there. Maybe the neoliberals are onto something and I should switch teams. I don't want to clean up other people's shit either.

Re:Better drivers and more of them

[suv4x4]

A stable kernel api for drivers is what linux needs as proprietary driver writers make poor quality and buggy implementations.

You can't have a "stable kernel api for drivers". The kernel might be super stable but since it gives kernel mode access to the drivers, the drivers can still crash the system if poorly written.

That's after all, the entire problem, and why we have userspace drivers. And why Vista has userspace drivers.

Re:Better drivers and more of them

[Roydd McWilson]

Dude, stable in this instance also means does not change with different kernel versions. One of the issues prop devs've had is building a bin driver that loads into arbitrary kernel versions 'n builds. Moreover, with proper type chicken, you c'd p'tentially run crappy drivers inside the kernel at no bigger risk than in user mode.

Re:Better drivers and more of them

[suv4x4]

Moreover, with proper type chicken, you c'd p'tentially run crappy drivers inside the kernel at no bigger risk than in user mode.

Yea sure, with proper type of glasses everything around you will be pink. You better do a research on why bad code running in ring 0 can always hang the system never mind the API.

Re:Better drivers and more of them

[Anonymous Coward]

i suppose what i'm really against is technology being used to restrict the freedoms and capabilities of the individual
In the case you're arguing for, how is the technology restricting the freedoms and capabilities of the individual?
You can still work out yourself how to communicate with the device, you can still work out the motherboard connections etc. What you really want is a free handout. The companies that make tech products are under no obligation, moral or otherwise, to help you there. The only moral obligation I see them as having is not preventing you from figuring it all out yourself.

Re:Better drivers and more of them

[SanityInAnarchy]

You better do a research on why bad code running in ring 0 can always hang the system never mind the API.

You'd better do some research on... well, English grammar, first, but also check out systems like Java, Flash, JavaScript, Silverlight (and the rest of .NET), and so on. It is possible to run untrusted code in the same address space as trusted code. It should therefore be possible to run untrusted code in ring 0. Done right, you'd get a performance boost to everything, by running absolutely everything (except legacy apps) in "kernel mode" / ring 0, and no more security risk than you had before.

Yes, I'm aware that a Javascript, for instance, can currently hang the browser, or crash it, or even sometimes get into things it shouldn't be able to (like the user's files). All of this is due to buggy implementations. I think we may have enough practice by now to be able to do this right, if we start from the ground up.

The downside is, it would be incredibly difficult to do this with precompiled x86 stuff at all, and probably impossible to do it without a performance hit compared to simply running in its own address space. I'm not even sure it could be done efficiently with C source -- it would most likely have to be a sufficiently high-level bytecode language, at least.

Which means that, probably, no one will ever do it. In order for this to work, it'd have to both be sufficiently better than Linux to get a majority of Linux developers to move over, and it'd have to support all the old Linux drivers, at least, until they could be rewritten.

Re:Better drivers and more of them

[adamofgreyskull]

They are hardware manufacturers. They sell hardware. What the fuck do they have to worry about if they provide documentation on the interface between their hardware and the hardware under my desk? Am I going to suddenly be able to infer the entire design of their hardware (or the source of the drivers they've written for windows), just because I have that knowledge?

Am I missing something here?

Re:Better drivers and more of them

[Roydd McWilson]

It is possible to run untrusted code in the same address space as trusted code.

Fo sho, or more aptly, you trust the code not cuz some smart fucker wrote it, but due to the fact you fuckin' PROVED it safe relative to yer favored semantics.

The downside is, it would be incredibly difficult to do this with precompiled x86 stuff at all, and probably impossible to do it without a performance hit compared to simply running in its own address space. I'm not even sure it could be done efficiently with C source -- it would most likely have to be a sufficiently high-level bytecode language, at least.

True 'nuff to some degree, however, a nigga could see translatin' C to a stylized "driver C"... and WOAH! sneak in some type safety 'n shit. Toss in linear types, effect analysis, critical section termination, resource bounds... damn!

Which means that, probably, no one will ever do it. In order for this to work, it'd have to both be sufficiently better than Linux to get a majority of Linux developers to move over, and it'd have to support all the old Linux drivers, at least, until they could be rewritten.

Dem's da breaks, ain't dey? Ah one day one day ma pretty. The ol' em-dollarsign's got Singularity, but you know, them ain't no Linux friendly buncha bastards.

Re:Better drivers and more of them

[SanityInAnarchy]

While this is not a kernel one its a good compromise as proprietary drivers are here to stay as much as it would be great if we had free gnu ones inside the kernel.

No, they are not.

It's happened before -- Broadcom for example. For the longest time, you could only run broadcom wireless with ndiswrapper. Now there's an open driver. You need only copy the firmware out of the Windows/OSX driver, and I imagine there might even be some free firmware developed eventually. This doesn't mean ndiswrapper is dead -- I'm sure there are other cards that still need it -- but Broadcom wireless cards now likely work better with the bcm43xx driver than with ndiswrapper.

Sometimes, it even happens with the manufacturer's blessing. For the longest time, the only way to get stuff on your nForce board to run was to load nVidia's proprietary nForce drivers. Now, nVidia never released source -- and perhaps couldn't, because of license restrictions -- but they now strongly recommend using the open "forcedeth" driver, which has surpassed their own in functionality and stability, and is actively supported by the kernel developers.

And sometimes, the manufacturer actually does it themselves. Though IBM kind of did a bad job of coordinating with the community, they did port Linux to their bigiron mainframes, and they did finally release all source back to the community.

Some manufacturers even seem to do this from the start -- syskonnect, for example, has full source code for a Linux driver available for download on their website, although I believe the kernel-maintained sky2 driver has surpassed their "sk98lin" driver.

So I don't think it's unreasonable that, very soon, you'll be able to build a Linux system without any proprietary code in ring 0. You might still want the win32codecs, say, but that's a different matter -- I don't really care if my movie player crashes once in awhile if it doesn't bring down my whole system -- and many of these are being replaced by free/open drivers.

In fact, you can do that now, if you're careful with your hardware choices. The only real hurdle to a desktop/laptop system with a completely open kernel is gaming -- you really want nVidia or ATI. It's been said that AMD/ATI are looking at opening up their drivers, and nVidia has actually produced a list of exactly what licensing issues they have -- I think they even named names of which companies have to sign to allow them to release all of their source. And anyway, if it doesn't happen, the community isn't waiting -- there is already at least one project attempting to create an open nVidia driver, and there have always been open drivers for older ATI cards.

IT would be cool for hardware makers to have a driver that works with all operating systems with minimal effort in porting.

Porting isn't the problem. Really.

All it would take, in many cases, is a hardware manufacturer releasing source for their Windows driver, and there'd probably be a Linux port out before the end of the week. We don't even need source code for all of them, of course -- just look at ndiswrapper and captive-ntfs -- but I think that just goes to show how easy it would be if we did have source, and they would perform better that way anyway.

I also remember seeing some quote somewhere that nVidia shares roughly 95% of their code across all platforms. Consider what they support -- Linux, BSD, Windows, OS X, I think they might even have Solaris in there somewhere. It's not unreasonable to think that the bigger and more complicated your driver is, the less of it needs to be platform-dependant.

Any program that can't easily be ported isn't modular enough to begin with.

No, I suspect the real problem proprietary manufacturers have is fear of licensing issues -- which userspace might help with, if they want to keep it proprietary -- and support issues. It's one thing to simply port to a different platform; it's another issue entirely to have QA,

Re:Better drivers and more of them

[Tony Hoyle]

Done right, you'd get a performance boost to everything, by running absolutely everything (except legacy apps) in "kernel mode" / ring 0, and no more security risk than you had before.

Seriously dude, read a book on OS design and realize how utterly wrong that statement is.

Re:Better drivers and more of them

[DrSkwid]

> A stable kernel api for drivers is what linux needs as proprietary driver writers make poor quality and buggy implementations.

Now they can write poor quality and buggy implementations against another API.

Re:Better drivers and more of them

[baadger]

I tried for days to get WPA and WEP working with the native bcm43xx driver and failed. The thing would receive wireless traffic (I could stick the card into monitor mode and capture packets from the air) but refused to connect to anything but unencrypted networks.

This may have been because the native Broadcom driver doesn't support the latest firmware (v4). I gingerly installed ndiswrapper and it just started working, and as an added bonus I can use the whizz cool Network Manager.

So the native Broadcom driver is still immature, i'm keeping an eye on it...

Re:Better drivers and more of them

[ZorbaTHut]

Keep in mind how much of a modern graphics card's abilities are now located in software. More than once, a driver update has come out that has *massively* boosted graphics card speed. I suspect that modern graphics cards are really just ultra-high-speed multicore floating-point coprocessors, and most of the scene logic happens on the CPU. I wouldn't be surprised in the least if the interface between CPU and graphics card was a tightly guarded secret - main bus bandwidth, and bandwidth in general, is one of the major bottlenecks on graphics systems right now.

To make it even worse, I'm told that many wifi cards are only legal because they're not open-source. Sound bizarre? When they're sold, they're sold with certain restrictions on frequency and power. These restrictions are located entirely within the drivers. If they distributed open-source drivers, those restrictions would either have to be moved into hardware (expensive) or disabled (causes horrific problems with the FCC.)

We're well past the point where hardware interfaces can be described in half a dozen pages. We're well past the point where "hardware devices" even exist entirely in hardware. Most interesting hardware devices have complex interfaces that depend on functioning backend software.

Re:Better drivers and more of them

[Sam Douglas]

Kernel mode or "Ring 0" (on Intel and similar systems) means that the program can execute any instruction, change any CPU settings, access all memory and IO devices. [This is bad for running arbitrary and possibly poorly written code!]

The examples you gave with Flash etc. are a completely different situation.

-- Sam

Re:Better drivers and more of them

[suv4x4]

You'd better do some research on... well, English grammar, first, but also check out systems like Java, Flash, JavaScript, Silverlight (and the rest of .NET), and so on. It is possible to run untrusted code in the same address space as trusted code. It should therefore be possible to run untrusted code in ring 0. Done right, you'd get a performance boost to everything, by running absolutely everything (except legacy apps) in "kernel mode" / ring 0, and no more security risk than you had before.

But of course. Running drivers on JavaScript in ring 0. You're a fucking performance genius.

Re:Better drivers and more of them

[Jah-Wren Ryel]

Am I missing something here? Yeah. Patents.

They are afraid that by providing documentation on interfaces, it may tip-off a patent holder to start looking for infringement where they might not otherwise have done so.

After all, when the prevailing legal advice is to actively not look for pre-existing patents, it is inevitable that companies will independently create infringing hardware. It's like we get the worst of both worlds - patents might as well be trade-secrets since reading them is a legal mine-field if you are working in the same area, but we also get government enforced monopolies that stifle competition.

At least the lawyers get paid for their contributions,
and that's all that should really matter in the end. Right?

Re:Better drivers and more of them

[TheRaven64]

He's not wrong, he just has a lot of faith in type theory. This is the principle behind JNode and Singularity. If you're still reading books on OS design from the '80s or '90s, you might want to pick up a newer one (or, better, a copy of a recent journal in the field).

The problem with this is that, since modern CPUs all use untyped memory semantics, they are forced to use typed-variable semantics, rather than typed-value, making the whole system no fun at all to program (unless you're into B&D languages).

Re:Better drivers and more of them

[TheRaven64]

If the API is stable, then they can spend time fixing bugs that they used to spend updating their code to today's API.

Re:Better drivers and more of them

[ray-auch]

Am I going to suddenly be able to infer the entire design of their hardware (or the source of the drivers they've written for windows), just because I have that knowledge?


No - but that isn't their argument.

Suppose you get an email from Ferrari saying their new API for their F1 car has control functions for a moveable floor.

Will that enable you to infer the entire design of their car ? - No.

No suppose Maclaren get that email. Will it affect the competition between them and Ferrari ? - quite possibly.

In both cases, I don't know enough to decide if the argument is completely valid - but both are credible.

Re:Better drivers and more of them

[Haeleth]

To make it even worse, I'm told that many wifi cards are only legal because they're not open-source. Sound bizarre? When they're sold, they're sold with certain restrictions on frequency and power. These restrictions are located entirely within the drivers. If they distributed open-source drivers, those restrictions would either have to be moved into hardware (expensive) or disabled (causes horrific problems with the FCC.)

This makes no sense whatsoever. Why can't they just release the driver source code with a note adding that it is illegal to use the driver if you remove the restrictions?

You might as well say that it is illegal to make open-source FTP programs, because only closed-source FTP programs could include effective restrictions to stop them being used to download child pornography.

Re:Better drivers and more of them

[smallfries]

I haven't looked at the API so I don't know if this would true (disclaimer aside), but if there is a stable API between the user-space part and the kernel - doesn't that make reverse engineering from a trace easier? If I can perform action A 20 times, and then check a log of the driver traces from the kernel then I can infer which bits to twiddle to make things happen. Anyone know if this is the case?

Re:Better drivers and more of them

[Ornedan]

Except we're talking about commodity hardware here, so the competitor can get their hands on the actual hardware. And assuming they are not totally incompetent, they should be able to find out how that hardware works through direct examination.

Re:Better drivers and more of them

[Anonymous Coward]

This makes no sense whatsoever. Why can't they just release the driver source code with a note adding that it is illegal to use the driver if you remove the restrictions?

Because that's not good enough to appease the FCC; apparently, the legal barriers aren't enough for them--they insist upon technical ones as well.

I had exactly this conversation with one of the EMC engineers handling FCC certifications at my prior job; he said that not only does the FCC require binary-blob firmware, but the FCC has even been known to revoke the certification of a device if it becomes known that hackers have reverse engineered the closed firmware enough to change the limits.

Re:Better drivers and more of them

[drinkypoo]

More than once, a driver update has come out that has *massively* boosted graphics card speed. I suspect that modern graphics cards are really just ultra-high-speed multicore floating-point coprocessors, and most of the scene logic happens on the CPU.

I don't know precisely what the situation is here but my understanding is that at least older geforce cards specifically implemented pretty much all of Direct3D directly on-card. The driver basically handled configuration and errata - when they fuck up the hardware, they fix it in software. The driver will be more a map of their failings than a catalog of elite code.

Re:Better drivers and more of them

[kabz]

Where do I get this ... "JavaScript" ?

Re:Better drivers and more of them

[Skapare]

Keep in mind how much of a modern graphics card's abilities are now located in software.

Yes. But does that mean software that runs on a CPU on the graphics card, or software that runs on the system CPU, stealing cycles from it? The latter is what some manufacturers are doing, and should not be doing. For software that runs on the graphics card CPU, it doesn't need to run either in kernel space or user space ... that's another space we can call "hardware space". It has no access to kernel APIs or user APIs, nor should it have that.

Imagine for a moment if X Windows were the universal graphical system on (nearly) call computers. It isn't due to the likes of Microsoft, but just imagine it were. What we could have is a graphics card with a CPU on the card that implements an X Windows server. Then all you need is a way to shuffle all the messages that go between applications and X across the bus between system CPU and graphics card.

Now X might not be the best interface design, and certainly would not be for gaming, a better design certainly can be made. But even X would be faster than it is now with the server on the card (quite doable today). And still, the window manager would run in user space.

I wouldn't be surprised in the least if the interface between CPU and graphics card was a tightly guarded secret - main bus bandwidth, and bandwidth in general, is one of the major bottlenecks on graphics systems right now.

That interface should be nothing more than the information of what the system and applications expect the graphics card to display, an encapsulation protocol to organize it into messages and responses, and a basic way to stream it across the bus (like PCI-Express x16, for an example with high performance). Those messages may possibly be a reflection of the graphical API calls done by the applications.

... those restrictions would either have to be moved into hardware (expensive) or disabled (causes horrific problems with the FCC.)

What do you think is happening now with quite a number of wireless routers being booted (or boosted) with Linux or BSD on them?

We're well past the point where hardware interfaces can be described in half a dozen pages. We're well past the point where "hardware devices" even exist entirely in hardware. Most interesting hardware devices have complex interfaces that depend on functioning backend software.

That is certainly something that is happening. But it most certainly is not something that is necessary. What we have these days in designs are the result of companies trying to cut their costs with the consumers be damned. These are bad designs, not so much because they steal CPU power from the consumer's computer, but more so because they create these massively complex interfaces that keep changing all the time, and driver code that is so buggy it is frequently the source of systemwide crashes or data corruption. At least if that buggy code is moved into a process, it can do its thing without taking down the whole system.

But we shouldn't have to be doing that. The hardware specific code should be inside the hardware, running on the CPU that comes as part of that hardware. Upgrades can be provided by the system CPU as a checksummed and, if necessary, cryptographically signed, blob (via a unified firmware image upload interface design that all devices should share that includes device match checks to be sure the correct image is loaded). Then maybe we'll start getting some real value add out of things like video cards, instead of getting cards that result in a net loss of CPU power when added in.

Re:Better drivers and more of them

[AaronLawrence]

It's becoming fairly obvious that when you buy a video card, a big part of the cost is the incredibly complex driver to make use of that hardware and implement the whole directx|opengl API.

Re:Better drivers and more of them

[suv4x4]

He's not wrong, he just has a lot of faith in type theory. This is the principle behind JNode and Singularity.

If you'll be claiming that he's not wrong (i.e. that running everything in a virtual machine in ring 0 brings much better performance), at least don't support this with examples of experimental OS that are lacking in the performance department (despite the little win of software-only context switch).

Re:Better drivers and more of them

[ZorbaTHut]

Keep in mind that truly modern 3d drivers include, at the very least, an optimizing compiler for pixel and vertex shaders.

I suspect most drivers include far more. We've come a long way since the first Geforce cards.

Re:Better drivers and more of them

[DrSkwid]

I expect one of the calls will be syscall(id, ....); and they'll be back where they started.

Re:Better drivers and more of them

[ZorbaTHut]

But does that mean software that runs on a CPU on the graphics card, or software that runs on the system CPU, stealing cycles from it? The latter is what some manufacturers are doing, and should not be doing.

Why not?

Seriously, why not? Do you honestly think they should be building an entire separate general-purpose CPU, and putting that on the graphics card? If they can achieve better FPS - overall FPS, including what's "stolen" from the CPU - by putting heftier more special-purpose hardware on the video card, and falling back to the CPU for the stuff the video card can't do well, why shouldn't they?

I fork over money for graphics cards because they make my games look better and play better. Fundamentally, I don't much care how they do that.

Yes, obviously, moving more stuff to the graphics card would be faster. It would also be more expensive. If there are better ways for them to use the transistors, it's fine by me.

That interface should be nothing more than the information of what the system and applications expect the graphics card to display, an encapsulation protocol to organize it into messages and responses, and a basic way to stream it across the bus (like PCI-Express x16, for an example with high performance). Those messages may possibly be a reflection of the graphical API calls done by the applications.

What we have these days in designs are the result of companies trying to cut their costs with the consumers be damned. These are bad designs, not so much because they steal CPU power from the consumer's computer, but more so because they create these massively complex interfaces that keep changing all the time, and driver code that is so buggy it is frequently the source of systemwide crashes or data corruption. At least if that buggy code is moved into a process, it can do its thing without taking down the whole system.

But we shouldn't have to be doing that. The hardware specific code should be inside the hardware, running on the CPU that comes as part of that hardware. Upgrades can be provided by the system CPU as a checksummed and, if necessary, cryptographically signed, blob (via a unified firmware image upload interface design that all devices should share that includes device match checks to be sure the correct image is loaded). Then maybe we'll start getting some real value add out of things like video cards, instead of getting cards that result in a net loss of CPU power when added in.

Why? You're making claims, but you're not backing them up.

Here's what I see. I see that I can go to the store and pick up a new graphics card. I can plug it into my computer and suddenly my games run significantly faster. Now, if I have a choice between Card A and Card B, and they're identical in every effective respect except that Card B makes my games run 10% faster with better shadows and uses some nasty techniques to do so that I completely don't have to care about, I'm buying Card B. There might be philosophical arguments to be made about whether Card A or Card B is better, but in all honesty, I see these philosophical arguments as similar to the whole Hurd vs. Linux debate. Okay, Hurd might be "better" - but Linux works.

What they're doing with the cards right now works. They've poured millions of man-hours into making them as fast as humanly possible within budget. If they determine that it's best to use CPU power for some things, make the GPU into a half-FPGA, and use a complex binary protocol that changes based on how the GPU is programmed, and they can make all of that stable - and my computer literally hasn't bluescreened in a year, so I'll give them that much - I think, just maybe, you should respect that they're making the right decisions for the priorities that people have. Which, generally, is game performance per dollar.

If you want to keep metaphorically extolling the virtues of Hurd because it's "better", though, I'm certainly not going to stop you.

Re:Better drivers and more of them

[ScrewMaster]

Interesting. Now I have a wireless router running alternate firmware, and one of the options is to adjust output power from 1 to 251 mw, which would be way above the legal limit, I understand. As it happens, I used that option to reduce the power from the stock value, since the computers upstairs work fine with the router set to 24 mw. In my case, having that capability reduced my chances of causing unwanted interference. Not everyone wants to blow away their neighbors. Also, since the router is located in the basement and is running at minimum power, it's very hard to pick up a signal outside my house, and that's the way I want it. Encryption is all well and good but if they don't know it's there, so much the better.

Re:Better drivers and more of them

[level_headed_midwest]

They could, and with the signed drivers being required for at least 64-bit Vista, they could enforce it. But I'd be VERY willing to bet that if Microsoft even hinted at this, the hardware maker would just have to threaten to call the DOJ and Microsoft would backpedal faster than you could say "antitrust."

And you also mentioned the other solution if Microsoft does make threatening noises. With both the Windows and Linux kernel driver APIs being stable, it should be trivial to make a translation wrapper between the two. MS would have their hands tied in keeping drivers off Linux if that happens as they'd have to stop their own driver development. MS needs as many good drivers as they can get for even 32-bit Vista, let alone anything 64-bit. If I were Microsoft, I'd be helping out all I could to get a stable wrapper or translation layer so that a "universal" driver for both Linux and Vista could be made by device manufacturers. Vista notoriously lacks drivers, especially Vista 64-bit, and Linux has enough to make most things work, especially for corporate machines and in server rooms. Both of those areas are ones that are much more likely to consider switching to Linux from W2K/XP than to Vista than the ordinary Joe. Or they will sit on XP like many sat on W2K until around the time XP SP2 came out. Both results would give MS no sales, and since they are also MS's most profitable markets, not upgrading to Vista would be a serious blow to MS. So I think that taking a risk that some previous 2K/XP switch to Linux because of more driver support is far outweighed by the increased number of Vista sales because of better driver support.

Re:Better drivers and more of them

[Blakey Rat]

Well, if it's a wireless card, you can get their product banned in some countries by violating their radio frequency laws, regardless of whether you wrote the driver or some random Joe did.

Seriously, there are very very good reasons for hardware to not be documented if you're a hardware maker and want to stay in business.

Re:Better drivers and more of them

[deander2]

I suspect that modern graphics cards are really just ultra-high-speed multicore floating-point coprocessors

with the nv8xxx series, you're exactly right. 128 semi-independent 32-bit cores, and ass-loads of (unfortunately non-uniform) memory bandwidth.

ATI's latest however is quite a bit different. a smaller number (6-8 i think?) of ultra-wide 256-bit cores. (think transmeta)

there is a whole community of users btw co-opting these cards for non-graphics applications.

Re:Better drivers and more of them

[Surye]

Consider what they support -- Linux, BSD, Windows, OS X, I think they might even have Solaris in there somewhere. And FreeBSD!

Re:Better drivers and more of them

[Anonymous Coward]

> Imagine for a moment if X Windows were the universal graphical system on (nearly) call computers. It isn't due to the likes of Microsoft, but just imagine it were. What we could have is a graphics card with a
> CPU on the card that implements an X Windows server. Then all you need is a way to shuffle all the messages that go between applications and X across the bus between system CPU and graphics card.

I'm not big fan of MS, but I'm glad X Windows isn't universal. If I want a crappy GUI I'd still be using Norton Commander on DOS

Re:Better drivers and more of them

[pD-brane]

A stable kernel api for drivers is what linux needs as proprietary driver writers make poor quality and buggy implementations. While this is not a kernel one its a good compromise as proprietary drivers are here to stay as much as it would be great if we had free gnu ones inside the kernel.

Even though I cannot say for sure whether this last sentence is grammatically correct, it is truly too complicated.

But now on topic: I personally do not care if it is easier for manufacturers to make the implementation of proprietary drivers easier. I could even argue that this is a bad development and makes free driver development, and moreover open specification, less important for the hardware manufacturers. This is just a possible bad side effect to a userspace driver API; it is an sich a good thing.

Re:Better drivers and more of them

[jZnat]

What countries? Name them.

Besides, something that controls the power usage on the wireless card should be built into the fucking hardware, not controlled by an easily hackable blob. Speaking of which, with what you said, I'm sure it would be trivial to figure out how to get any and all wireless cards banned in those countries because no wireless card is invulnerable to hard hacking by a clever engineer.

Re:Better drivers and more of them

[lordtoran]

You can have the same amount of speed and reliability in both. Not always correct. A driver in userspace has to do a (time consuming) CPU context switch every time it talks to the hardware. Especially with high-troughput hardware like graphics cards, this may impose a limit on the bandwidth if not managed well. On the other hand, a buggy driver in userspace cannot easily crash the kernel. So, since the bugginess of proprietary drivers is a constant nuisance under Linux, I welcome this method of keeping that stuff out of kernel land. The stable API benefits everyone. The driver maintenance effort for the hardware manufacturers is lower, it may result in more brand new hardware being supported by at least a proprietary driver, and the kernel is not "tainted" by non-GPL modules.

Re:Better drivers and more of them

[SanityInAnarchy]

True 'nuff to some degree, however, a nigga could see translatin' C to a stylized "driver C"... and WOAH! sneak in some type safety 'n shit. Toss in linear types, effect analysis, critical section termination, resource bounds... damn!

One wonders how useful C would be at this point, though. The only reason I see of keeping it C is for porting old code, and the old code is probably going to make lots of assumptions about the capabilities of C that we'd be taking out.

Of course, there's also the massive pool of developers who already know C, but if you know C, it's not that difficult to learn something similar (C++, Java, C#, etc).

Re:Better drivers and more of them

[Anonymous Coward]

Correct about Nvidia (G80), except those 128 FP32 scalar engines are augmented by (texture) samplers and other stuff (beyond simply FMADD complexity). ATI's latest (R600) has 64 engines of 4xFP32 vector + FP32 scalar, divided into four groups of 16 engines. (Theoretically R600 packs a much heavier punch, in practice -- in latest games -- the G80 races neck to neck, so these descriptions are probably way oversimplified.) 256-bit (4xFP64) engines would go to waste, as FP32 per color channel is already *almost* overkill for high dynamic range... except when "general-purpose GPU" usage becomes more common... except that the graphics pipeline workflow isn't all that cracked up for the majority of computational tasks; some simulations being a notable exception.

Re:Better drivers and more of them

[LarsG]

What countries? Name them.

Any country who has an FCC or equivalent. Naming those that don't would be easier.

something that controls the power usage on the wireless card should be built into the fucking hardware, not controlled by an easily hackable blob

Problem is that different countries have different rules. Both for power output and which frequency bands can be used. Making one chip for Japan, one for Europe and one for USA isn't very efficient so manufacturers like Broadcomm and Marvel make more generic chips and load firmware that implement the local rules.

I'm sure it would be trivial to figure out how to get any and all wireless cards banned in those countries because no wireless card is invulnerable to hard hacking by a clever engineer.

But that's user modification, that's unlikely to get the manufacturer banned.

Re:Better drivers and more of them

[SanityInAnarchy]

The examples you gave with Flash etc. are a completely different situation.

Are they?

Let's take Java. A plugin written in Java on a 32-bit system (because the lazy bastards haven't ported the plugin architecture to 64-bit) runs in the same address space in the browser. That means that Java can execute any instruction in the browser, and access anything the browser has access to. It means, in short, that unless you're running something like Internet Explorer on Vista, loading an untrusted plugin into your browser means that plugin can do anything it wants to your system as your user.

So, from a stability standpoint, it could crash your browser -- every last tab of it. From a security standpoint, it's often no better than a kernel-level compromise, because for most people, all of their data is in /home anyway.

So what I'm talking about is not the extent of the damage if your Java plugin were to go haywire. What I'm talking about is the fact that it doesn't. Java lets you run arbitrary, untrusted applets from the Internet, and even just-in-time bytecode compile them to native code, without ever posing a risk to the rest of your system, or even the rest of your browser.

I don't feel like explaining why this works, because that's what I think you need to go research. But I feel that this approach can be done more efficiently and more securely than simple memory segmentation.

In other words:

[This is bad for running arbitrary and possibly poorly written code!]

So all you do is evaluate the code before it's run to make sure it doesn't do stuff like that. You could even have the programming or bytecode language be restricted from doing certain things -- type checking is a simple example, because there's really no reason for you to ever confuse an integer with a pointer anymore, or to do arithmetic on a pointer in most programs.

Here's another hint: buffer overflows are possible in languages like C and C++. They are not possible in most interpreted or bytecode languages -- at least, if the Java runtime itself doesn't have a buffer overflow, you cannot write a Java program which has one.

Re:Better drivers and more of them

[SanityInAnarchy]

Out of all the things I mentioned, you picked JavaScript?

Yes, I realize there isn't really a VM out there that's capable of everything I'd want for this system. That doesn't make it impossible.

Re:Better drivers and more of them

[SanityInAnarchy]

I said "BSD" because I assumed if they supported FreeBSD, they probably also supported OpenBSD and NetBSD and everything.

Re:Better drivers and more of them

[Anonymous Coward]

Why not? Seriously, why not? Do you honestly think they should be building an entire separate general-purpose CPU, and putting that on the graphics card? If they can achieve better FPS - overall FPS, including what's "stolen" from the CPU - by putting heftier more special-purpose hardware on the video card, and falling back to the CPU for the stuff the video card can't do well, why shouldn't they? Well lets look at video cards, and how they have evolved. The very original cards did nothing but receive a set of instructions that told it which color to use for each pixel. The color choices were limited. They were usually a fixed pallet. They occasionally had support for sprites, where a sprite could be uploaded, and then a command could be sent to tell the chip where to display the sprite. Some cards added generic blitting support, which is one of the simplest 2d acceleration techniques. VGA comes along. VGA combines the basic DAC with some limited 2d acceleration support. VGA has a pallet of 256 colors. However it was implemented as a group of 4 pallets of 64 colors. Thus only 64 colors could be displayed at a time. But switching between the four pallets was a fast operation. Further the pallets were customizable. The each pallet entry could be assigned one of 262,144 colors. There was also the mode 13h, which basically allowed access to all 4 sub-pallets at once. Thus the restriction was a pallet of 256 colors chosen from 262,144 possible colors. VGA standard had some limited raster ops support, and had a standardized frame buffer mechanism. It supported double buffering in the 16 color modes. Some hacks allowed double buffering in 256 color mode. However, the support were fairly limited. At the same time as VGA was released the first full 2d-accelerators were coming out. While not programmable, they accepted commands such as "Draw a circle of radius X at (X,X) in color X)." Prior to this point expensive general purpose co-processing boards could be used to accelerate graphics. Otherwise the main CPU had to do all the work. Now eventually we get to the point where Windows has come along. Windows used a fairly fixed API. So while the cards continued to support direct access graphics they started adding some hardware support for certain commands found in window's GDI interface. This is the beginning of the current situation. The drivers would receive the GDI commands. If the card has special support for the command, the command would be passed to the card. Otherwise the driver would perform the command in software and display it using the direct access mechanism. The important thing to note here is that while the direct access drawing commands were well documented, the commands to access the special GDI accelleration functions the card implemented was not documented. When 3d acelleration came around the system worked the same way. The internal commands were not documented. The drivers translated between the API and the undocumented internal commands of the chip. With the advent of shaders the GPU's were once again programmable, but now the base command set of the chip is still secret. We only know the 2d and 3d acceleration APIs, and the direct access commands.

Re:Better drivers and more of them

[Roydd McWilson]

True 'nuff to some degree, however, a nigga could see translatin' C to a stylized "driver C"... and WOAH! sneak in some type safety 'n shit. Toss in linear types, effect analysis, critical section termination, resource bounds... damn!

One wonders how useful C would be at this point, though. The only reason I see of keeping it C is for porting old code, and the old code is probably going to make lots of assumptions about the capabilities of C that we'd be taking out.

Of course, there's also the massive pool of developers who already know C, but if you know C, it's not that difficult to learn something similar (C++, Java, C#, etc).

Dude I ain't dissin' ya proposition, but we both know it's all 'bout the sales. Crusty ol' devs like their crusty ol' C. Gotta ease it in. Writin drivers in a totally sound modern language 'n shit'd rock veritably, no kiddn, but we can't be neglectin' tha success o' MISRA-C, SystemC, 'n fuck knows what all else.

Re:Better drivers and more of them

[Roydd McWilson]

He's not wrong, he just has a lot of faith in type theory. This is the principle behind JNode and Singularity.

If you'll be claiming that he's not wrong (i.e. that running everything in a virtual machine in ring 0 brings much better performance), at least don't support this with examples of experimental OS that are lacking in the performance department (despite the little win of software-only context switch).

WTF you talkin' 'bout? Singularity's FASTER than Windows, Linux 'n FreeBSD at at IPC, file transfers, data streamin', and otha tight shit like that! Moreover, slightly fast + safter = strictly cooler regardless, dude.

Re:Better drivers and more of them

[Roydd McWilson]

The problem with this is that, since modern CPUs all use untyped memory semantics, they are forced to use typed-variable semantics, rather than typed-value, making the whole system no fun at all to program (unless you're into B&D languages).

Yo safety first 'n all, but we got a lil thing called type inference for yall artsy-fartsy whiny bitches. I'll give ya a combinatorial argument here: if yo language can do LESS (but still accomplishes whateva the hell you actually need), there's FEWWA OPPORTUNITIES fo' runtime bugs! Straight up simple's that. So don't be dissin' my statically-typed homeboys callin' 'em all inta B&D an' kinky shit like that!! Sounds ta me mo like you're just an incontinent fuck liable to crap all over tha place if the CPU don't be wastin' its valuable r'sources ta check on ya diapers all the time. Keep it rational, yo.

Re:Better drivers and more of them

[PitaBred]

Unfortunately for every one of someone that does that like you and I, there are ten bozos who don't get good enough reception so will just crank up the power. They'll find it on a message board somewhere and think it's a great idea, then you'll get all kinds of issues.

Re:Better drivers and more of them

[PitaBred]

Not very efficient my ass. Just put another resistor on the board, and change the power output relative to it's value. Minimal cost, hardware lock that'd require soldering to fix, rather than just code. That should indemnify the hardware manufacturer from any wrongdoing, and still allow open drivers.

And I'm not even an engineer. If I can figure that out, then I guarantee you someone else can. It's all about corporate paranoia. Lots of businesses have all kinds of things they lock down for no good reason except for paranoia.

Re:Better drivers and more of them

[Garridan]

i would personally like to see all pieces of hardware sold with schematics for the hardware. with other products, like cars, this is trivial anyway--anybody can open up the car and see what bit goes where. with computer hardware, because of things like microcode, this is impossible. You don't know much about cars, do you? For the past decade or so, every BMW to come out has had a microcontroller, or a handful of them, for every mechanical part in the car. Pretty much every other manufacturer has followed suit. Starting around 1984, every American car had a computer. They were mostly diagnostic... but they started getting more and more invasive. Now, a friend who works in a repair shop spends *most* of his time there upgrading firmware.

And no, you can't see the schematic.

Re:Better drivers and more of them

[ray-auch]

So, remind me, why was it we needed all the secret documentation to write drivers then ?

Re:Better drivers and more of them

[LarsG]

You seriously need to get out a bit.

Re:Better drivers and more of them

[Blakey Rat]

Maybe it's about reducing cost so they can, you know, stay in business? So that rabid foaming-mouth open source zealots like you have wireless cards at all.

Sure they COULD make a different card model for each country and ship each model only to that country. But when their competitors don't, they'd go out of business. This is called "reality"... you might want to get in touch with it.

Re:Better drivers and more of them

[Blakey Rat]

What countries? Name them.

Almost every country with more infrastructure than Liberia. But to give a more specific brief list off the poster on the wall at the last place I worked (helpfully provided by Fluke Electronics): USA, Japan, France, Germany.

Re:Better drivers and more of them

[networkBoy]

Just put another resistor on the board, and change the power output relative to it's value that requires extra pins and top layer board real estate if you use a voltage divider as you implied (one resistor can be internal to the part) then you also need an A/D converter, if you use GPIO style pins then you need3-7 pins for configuration. Either way costs go up, and in a market where $0.03 per unit will lose a design (my company lost the Xbox ethernet part that way) cheap as possible is the rule.
-nB

Re:Better drivers and more of them

[chromatic]

What you really want is a free handout.

It's not really a handout if I paid for the device.

Re:Better drivers and more of them

[mrsteveman1]

I've got plenty of cpu cycles, I'll trade some for stability, security, and easier driver installation and development.

Re:Better drivers and more of them

[TheNetAvenger]

but the vast majority of Windows drivers reside entirely in kernelspace

Um... No they don't unless you still think Windows 95/98 is 'Windows' of today.

Re:Better drivers and more of them

[FireFury03]

You are ignoring the fact that some of us are more interested in open 3D drivers than performance. If they produced Free technical documentation for the hardware interface, whilst we might not get _fast_ drivers, the Free software world can probably produce working open drivers.

I also think it's worth pointing out that despite the fact that the Intel chipsets I've got in some machines are technically less powerful than the nVidia chipsets, they generally run a *lot* faster. Why? Because the binary nVidia drivers are so buggy that you often have to enable hugely expensive work arounds for the system to be usable. Since the drivers are closed, noone except nVidia can fix the problem, and nVidia's bug-fix cycle seems to take in excess of 2 years and provides the end-user no visibility of the progress.

Re:Better drivers and more of them

[ZorbaTHut]

Sure, I can understand that, but you're still fighting the economic incentives.

Most people who buy hefty 3d graphics cards are gamers, and most gamers use Windows. The number of people who buy gaming graphics cards, install them on non-professional Linux boxes, and want them to have good 3d graphics, is approximately zero. (Yes, there's a market for professional workstation-class graphics cards, and I suspect they work just fine on the specific operating system versions with the specific hardware they're designed for. Gaming cards, games, and Bob's Awesome Linux Distribution fit none of those.)

Do you honestly expect nVidia to cripple 99.9% of their market in order to placate 0.1% of it? That's what changing the interface to be "simpler" would do.

Do you honestly expect nVidia to give up trade secrets in order to placate 0.1% of their market? That's what giving up the specs to their no-doubt carefully-tuned-and-precisely-designed PCIe interface would do.

Yes, what we have right now doesn't provide exactly what everyone in the market wants. Sometimes that happens. nVidia doesn't have even close to the financial incentive to open their drivers, and I honestly believe they're making the right financial decision. So, here we are.

And, honestly, it's not like 3d on Linux is completely impossible. As you've mentioned, Intel drivers are open - use Intel GPUs and it'll work just fine. Since you're more interested in open-ness than performance anyway, it shouldn't be a problem.

Re:Better drivers and more of them

[FireFury03]

Do you honestly expect nVidia to cripple 99.9% of their market in order to placate 0.1% of it? That's what changing the interface to be "simpler" would do.

Who said anything about crippling or simplifying anything - just publish specs for the existing interface. This doesn't require opening up the secrets of how the driver works, just the interface between the driver and hardware.

Do you honestly expect nVidia to give up trade secrets in order to placate 0.1% of their market?

In keeping something secret if it doesn't benefit you - I don't see how publishing interface specs harms them. If anything it might improve the value of their hardware by allowing more people to use it for non-standard stuff.

nVidia doesn't have even close to the financial incentive to open their drivers

Noone wants them to open their crappy unstable drivers - we just want the interface specs so we can write some Free drivers from scratch.

As you've mentioned, Intel drivers are open - use Intel GPUs and it'll work just fine.

Intel don't make discrete devices - they make integrated chipsets. If you don't have an Intel processor then you're SOL. I have no interest in replacing my entire machine in order to get 3D graphics, but I would replace my graphics card.

Re:Better drivers and more of them

[ZorbaTHut]

In keeping something secret if it doesn't benefit you - I don't see how publishing interface specs harms them.

It doesn't, directly. What it does do is help ATI and Intel quite a bit. That's where the "trade secret" part comes in.

Remember, nVidia isn't just trying to make good video cards. They're trying to make better video cards than anyone else. Giving your competitors the data you've spent millions of dollars coming up with and plan to make money off is very bad from a competitive point of view, and no company does this.

Re:Better drivers and more of them

[FireFury03]

What it does do is help ATI and Intel quite a bit. That's where the "trade secret" part comes in.

I very much doubt publishing the interface specs is going to help ATI and Intel.

Giving your competitors the data you've spent millions of dollars coming up with and plan to make money off is very bad from a competitive point of view

If they have spent millions of dollars just coming up with an interface specification then they've done something very wrong. The interface specification is also not something they "plan to make money off" - they are making money off the hardware (and would sell the hardware into new markets if they provided such information).

and no company does this.

That is fundamentally untrue - companies who base their products on Free software do this all the time and seem to do ok. They stay ahead of their competetors by producing better products (or better/more rapid improvements to the products) rather than preventing their customers from taking full advantage of the product. The Free software industry has shown that you _can_ run a business that collaberates with your competetors and the end result is good for everyone.

Unfortunately most companies ask the question "what information do we _have_ to hand out", rather than "what information can we hand out without harming ourselves" - the latter option makes for a better customer experience, doesn't harm the business and can also benefits the business by allowing customers to participate in the development activities at no cost.

Re:Better drivers and more of them

[ZorbaTHut]

I very much doubt publishing the interface specs is going to help ATI and Intel.

Why not? My entire point is that the interface is complex and the inner workings of it are finely tuned to the needs of modern graphics accelerators. That's not knowledge you get for free, and it wouldn't surprise me in the least if all three of those companies have come up with unique techniques for improvement (as well as missed techniques that the competitors found.)

If they have spent millions of dollars just coming up with an interface specification then they've done something very wrong. The interface specification is also not something they "plan to make money off" - they are making money off the hardware (and would sell the hardware into new markets if they provided such information).

That's true - and, as I mentioned before, the interface spec is an intrinsic part of the hardware. Modern hardware isn't "a chunk of silicon that the computer talks to via a hardware interface". Modern hardware is "a chunk of silicon and software that the userspace applications talk to via a software interface" - like OpenGL, or DirectX, for example. The drivers, and the interface, are part of the product.

That is fundamentally untrue - companies who base their products on Free software do this all the time and seem to do ok.

That actually is untrue. Most (if not all) free software companies make their money off support. The software isn't the product - the support is. Of course they're willing to give the software out for free, and do anything they can to improve it - better software means more people wanting support!

Now, if Redhat (as an example) posted all of their internal Linux documents and troubleshooting procedures online, and provided training for free, and asked that their support workers give out constant free help to random people in the community, then I'd agree that they were giving out their product for free. But Redhat's product isn't the OS. Redhat's product is the support. And that, they guard closely.

Re:Better drivers and more of them

[FireFury03]

That actually is untrue. Most (if not all) free software companies make their money off support.

Not true - you can buy supportless RHEL.

The software isn't the product - the support is.

When I buy a graphics card, the interface isn't the product - the hardware is. You can still sell hardware if the interface is documented, just as you can still sell support if the software is open.

Of course they're willing to give the software out for free, and do anything they can to improve it

So why aren't hardware manufacturers willing to give out specs for free? Remember, the hardware is the product, not the specs.

better software means more people wanting support!

Better hardware documentation means more people wanting the hardware.

Now, if Redhat (as an example) posted all of their internal Linux documents and troubleshooting procedures online

RedHat do post a lot of Linux documents and troubleshooting procedures.

and provided training for free

Noone's asking the likes of nVidia to provide training - just publish the specs. We can train outselves.

and asked that their support workers give out constant free help to random people in the community

Redhat developers give out constant free help to random people in the community (via the Fedora Project).

Redhat's product is the support. And that, they guard closely.

I think you have picked an extremely bad analogy which more or less proves my point. Red Hat's product is _not_ support. Red Hat's product is a support _contract_ which guarantees a level of service. You can get support elsewhere for free (even from Red Hat's developers themselves) - what you can't get for free is a _guarantee_ of support.

In the same way, nVidia's product is the hardware/software bundle - they make no money off the interface and would lose nothing by publishing the interface specs which would allow people buying the hardware/software bundle to throw away the software part and use the hardware with different software. This would increase the available market since the hardware could be put to other uses without expending any of nVidia's development time.

Re:Better drivers and more of them

[Ornedan]

Because there is non-zero amount of work involved in reverse-engineering how the proprietary drivers talk with the hardware. It can be done that way, but it's a major waste of effort.

Re:Better drivers and more of them

[ray-auch]

So... by keeping the docs secret, even for commodity hardware which my competitors can get hold of, I cause my competitors a "major waste of effort".

Corollary: if I publish the docs, I help my competitors.

That is the core of the argument, and it is (AFAICS) valid. What we need to do is convince mfrs that the benefits outweigh the disadvantages, rather than deny that the disadvantages exist.

Re:Better drivers and more of them

[Skapare]

You are ignoring the fact that some of us are more interested in open 3D drivers than performance.

Actually, by moving the graphical work to an on-the-card specialized graphics processor (or two), and limiting the bus bandwidth usage to just the informational aspect of what the application is requesting be done in graphics, then you can get both a big boost in graphics performance and an open interface at the same time (if that new interface is designed by someone without proprietary vested interests).

Consider the case of watching a movie. Why not have the graphics card itself decompressing the MPEG contents? Or would you rather your general purpose CPU be doing that and try to bottleneck your bus bandwidth pushing raw uncompressed video out? Of course passing the MPEG over the bus and letting the graphics card to the crunching work makes sense, if you have a video card that is capable (and quite many are).

Re:Better drivers and more of them

[Skapare]

Do you honestly expect nVidia to give up trade secrets ...

No, I do not. Your suggestion of that indicates that either you don't grok what I'm talking about, or I'm just bad at explaining it (or both). I'll try another way.

Let them keep all the proprietary stuff inside the card. A standardized interface could be message based (request/response). The kernel/OS driver would be little more than a tool to shuffle messages to and fro. The graphical libraries would form the messages from application API calls.

Then for gaming boosts, a set of specialized graphical operations that better coincide with what games need would be defined. The game developers could get this info under NDA from the video card maker. The game program would likely bypass libraries and supply whatever code it needs for itself. It would send one message to the video card and request the manufacturer and model ID and use that to select or activate the appropriate code to handle that card best. Most of the functions would be standardized, but specialized ones that games need can still be created by the card/chipset manufacturer and games could use those. This would still be requests sent in messages, utilizing direct unbuffered message queueing (e.g. the OS doesn't copy the message, but rather, schedules direct memory access I/O for the message right where it is in the game memory location). The OS won't care if the messages are the standard ones or the proprietary ones. It will just pass them along. Then the video card will do what it needs to do.

This gets the best of both worlds. Games can still have the specialized high performance graphical ops they want (if the video card in use has them ... they find out and use what is there, if they have that info from the manufacturers). The OS stands back and lets it happen, doing very little to just schedule the physical I/O accesses. Then when it's time to quit playing games and get real work done, one can boot into a safe OS and have a video card that still does very well with the standardized set of graphics card requests usable on any OS (because again, the OS just passes messages and the real work is done by the video card and the applications). The one exception would be some limited knowledge of the messages in the OS so the OS can display things itself, especially when booting up. That, plus a standard VGA compatibility so legacy OSes can also be used.

Re:Better drivers and more of them

[Skapare]

I agree with you (not with FireFury03) that opening up the interface they use now would be giving up at least some of their trade secret. I don't suggest that. Instead, I suggest using the message transport model. Within that they can still use their proprietary special operations, but do it in an interface where the layer of the system doing the access controls doesn't need to care about interpreting or understanding those messages. It would just know that the game is authorized for raw message access (e.g. the OS won't restrict some things like making sure an app is not reloading the firmware RAM) so anything the game sends goes to the video card. It would all be bulk direct memory transfers and would go faster over the bus than the tricky register juggling that happens now. A proprietary message may actually be a set of register IDs and values to load behind the scenes. But the OS won't need to care about that ... it's just between the game program and the video card.

And this will eliminate one of the hurdles to game makers making games for Linux/BSD (the game still closed source, but can run on the open source OS). In fact it may well work under Windows emulation, anyway.

Re:Better drivers and more of them

[Skapare]

I very much doubt publishing the interface specs is going to help ATI and Intel.

Actually, it can. It would reveal the specialized types of operations the video card can do. My alternative idea is not about exposing these specialized operations. Instead, it is about encapsulating them in messages that can utlize high speed direct memory access (what their interface is probably already in part doing, anyway) in a way where the OS and video card driver simply has no need to be concerned with the video operations (at least for "fully authorized" programs like the game being played, or the X server when doing "real work" if on Linux).

Re:Better drivers and more of them

[FireFury03]

Why not have the graphics card itself decompressing the MPEG contents?

This is already done to some extent - e.g. a number of graphics drivers have the XvMC extension, which allows offloading of MPEG2 motion compensation to the card. The problem here is that when a new codec appears you need to update the drivers (and maybe the hardware). For example, whilest the nVidia drivers provide XvMC support, they can't help with H.264 decoding.

Also, offloading all the decoding to the graphics card will limit the amount of post-processing you can do to the video since the CPU will not have access to the raw video (think: deinterlacing, special effects, etc).

Re:Better drivers and more of them

[Ornedan]

Why would the competitors want to write drivers for your hardware? Care to explain how you conjecture publishing API specs would help the competitors? Your example in your original post isn't valid, since you'll be telling the whole world about such great new features in your own damn marketing materials.

Do you really not understand that the documentation required for writing a driver is not the full hardware spec? The only people you will be helping by releasing an API doc is driver writers. Any competitors will still have to reverse engineer the hardware if they want to find out how it works.

Full circle?

[MichaelSmith]

Perhaps in ten years time Linux will be a microkernel

Re:Full circle?

[Goalie_Ca]

And the debate continues!

Re:Full circle?

[Tumbleweed]

Microkernels are the wave of the future.

And always will be. :)

Re:Full circle?

[giminy]

I've been thinking the same thing...first FUSE, now this. More and more of the kernel is going into userspace services, and these are the 'biggies.' It's really a welcome change. Albeit a strange one, given the great Torvald/Tanenbaum debate.

Re:Full circle?

[diego.viola]

I hope it will but I don't want to wait 10 years for that!

Re:Full circle?

[Pecisk]

Linux kernel are usually referenced as _hybrid_ type kernel. For example, Ubuntu and Debian built EVERYTHING they can in modules, so their kernels are more microkernels than monoliths.
But I really doubt that Linux will be pure microkernel sometimes, because...there is no need for it, _IMHO_.

Re:Full circle?

[bcmm]

Modularisation doesn't make it a microkernel. A loaded kernel module runs in kernel space just like any other kernel code, and will bring down the rest of the kernel if it crashes. A userspace driver (or one of the many daemon's doing all the interesting work for a true microkernel) should be able to segfault without bringing the kernel down.

Of course, if it's doing something really vital like managing the root FS (possible in a proper microkernel but not in Linux), you could be screwed anyway.

In any case, Linux will never be a microkernel because it is fundamentally not designed that way. A lot more than just the device drivers run in userspace in a true microkernel system (even if all the stuff Ubuntu modularises were in userspace, it still wouldn't be a microkernel). I believe GNU HURD has the POSIX API provided by a userspace program, for example.

Re:Full circle?

[baadger]

Torvald's is a pragmatist, if this is the same user space I/O framework I read about a while ago then there was a good case made for it when some guy ported a driver to it and significantly reduced the complexity and lines of code (and as I recall the number of ioctl's)

Window's has a userspace driver framework as well as a FUSE equivalent (I think) so really Linux isn't going any more toward being a micro kernel than Window's is.

Re:Full circle?

[bcmm]

I should point out that IIRC the Linux kernel has been made to run on top of the L4 microkernel. This is not the same as Linux itself being a microkernel.

Re:Full circle?

[baadger]

> Ubuntu and Debian built EVERYTHING they can in modules

andrew@ziggy ~ $ lsmod
Module Size Used by
nvidia 8105272 24
andrew@ziggy ~ $

Gentoo user ;)

Re:Full circle?

[init100]

Window's has a userspace driver framework as well as a FUSE equivalent (I think)

There are two ways to make new filesystems for Windows. You can make an Installable FileSystem (IFS) driver that runs in kernelspace, and you can make a Shell Namespace Extension to the Explorer shell. There is no shell-independent way of making userspace filesystems in Windows that I know of.

Note that I'm not a Windows programmer, but a Unix one. I did look into this however, when I was thinking of making an SSHFS equivalent for Windows, so that my friends and family could access my SSH server. I never got anywhere though, and settled for SftpDrive.

Re:Full circle?

[TheRaven64]

They probably will be now. Monolithic kernels give better performance on single-CPU machines, where you use shared memory for communication and don't want any context switches slowing you down. Microkernels with an asynchronous message passing mechanism, however, are better suited to large-scale multiprocessor boxes. With current hardware being 2-4 core, and this only looking to increase in the future.

Of course, now, a lot of the people who were saying microkernels were the future are saying that type-theory based kernels with no process boundaries (e.g. JNode, Singularity) are the future...

Re:Full circle?

[complete loony]

You can apparently (though I haven't looked into it much) run an SMB / CIFS server on the same machine.

Re:Full circle?

[Skapare]

You are right. But that doesn't make it right.

Re:Full circle?

[netcrusher88]

You're confusing where hybrid applies to Linux. It is a hybrid-monolithic macrokernel (hyphen added for clarity). Monolithic, meaning it's all in one piece. Hybrid-monolithic meaning it's all in one piece, but other pieces can be loaded into it on-the-fly. It's still a macrokernel - modules are not other processes - but not entirely monolithic.

Re:Full circle?

[Nimey]

SMB/CIFS isn't encrypted (though the password usually is) and it'd be another set of ports to have open on an Internet-facing machine.

I wonder if you can use CIFS over an SSH tunnel from a Windows machine, though...

Re:Full circle?

[petermgreen]

Of course, if it's doing something really vital like managing the root FS (possible in a proper microkernel but not in Linux
Why do you claim its not possible? Afaict an initrd can be used to mount a fuse filesystem to be used as the root filesystem.

Re:Full circle?

[bombshelter13]

>I wonder if you can use CIFS over an SSH tunnel from a Windows machine, though... Yes, you can.

Performance

[katterjohn]

Wouldn't implementing this in userspace drastically lack in performance compared to kernelspace drivers?

Re:Performance

[corychristison]

If you'd have read the article, you'd notice that it states firmly:

However, DMA transfer between userspace and kernelspace is not yet implemented. This means essentially that drivers which involve high traffic are not an option yet. So graphic drivers as well as file system drivers and similar cannot use this API at the moment.

Re:Performance

[Anonymous Coward]

FTA: "not yet implemented"...

The GP said, "in ten years time". Not quite sure I get your point.

Re:Performance

[jd]

There's a 21us hit every time you context-switch, which would hurt on very high-performance drives but is probably below the threshold of being obvious for network-based storage and really slow drives. However, a few intelligent drives supposedly support total kernel bypass and zero-copy - basically the drive remote DMAs the data into and out of memory, once told where things are. This would only require kernel access for initializing the transfer and locking down the pages. I seriously doubt, though, that any of these will be common uses for the userspace drivers.

The most common use, I would imagine, would be as a testbed platform. Writing things directly into the kernel has many unquantifiable variables - I'm highly respectful of all who develop kernel code on a regular basis, that is no small achievement. Developing the same code in userspace with an API to link over eliminates many of the possible ways you can screw up a machine, although the code would still need to be written with an eye to being used in kernel space. For much of the writing and testing, though, you'd be in a more predictable environment.

The second-most common use would be for proprietary closed-source drivers to be written for userspace. Writing them for the kernel is problematic as the kernel internals change too much, and many such companies spend so little on maintenance that the drivers rapidly become obsolete - requiring users to either use inferior kernels or different technology, with the latter often not being possible or practical. I don't imagine older Linux drivers to be ported this way, any more than they've been maintained by the pathetic commercial vendors who pull such stunts, but newer such drivers should now be less pathetic and marginally more portable, which will be good.

Oh, wrt comments by others, Linux should absolutely never become a microkernel. Message-passing as a methodology is barely adequate for networks - RPC and CORBA are hardly famed for their elegance or performance, and when was the last time you saw Globus or MPI being used to link machines in a LAN gaming session? For that matter, STREAMS has been available for Linux since about Linux 1.2, if I recall correctly. I can't think of a single driver - even outside any of the standard or experimental trees - that uses it. I like the idea of such a patch, as I like the idea of maximum flexibility, but if it were truly useful, it would be used. It isn't.

Re:Performance

[Anonymous Coward]

Nevermind. Its slashdot's gay new comment system being incompatible with Opera, mixing replies to posts.

Re:Performance

[Verte]

That's what, 80,000 cycles plus? That's ridiculous. All to save some registers and load a new LDT?

I agree on the Linux never becoming a microkernel, that would be a really ugly hack. But I think the kernels being developed today, the ones with memory essentially being a first class, sharable resource [such as Coyotos, which IIRC has an interface for sharing address spaces with other processes]. Once shared memory becomes simple and usable, we might see some nice new mk on top.

Re:Performance

[cryptoluddite]

Linux should absolutely never become a microkernel. Message-passing as a methodology is barely adequate for networks - RPC and CORBA are hardly famed for their elegance or performance, and when was the last time you saw Globus or MPI being used to link machines in a LAN gaming session? Uh you realize that anything object oriented is basically equivalent to microkernel? Each object is a separate 'memory space' that only it can affect, and all interaction is through 'messages' aka method invoke + wait.

An operating system would be so much better running a safe language. I program in C every day because of some requirements, and it is so much not a good language for operating systems. Most of what an OS does is manage lots of information and access to it. C is really, really bad at both of those... what it is is fast, but so much time in a system like Linux is wasted doing context switches and from overhead of using really really simplistic interfaces.

Just look at all the contortions libc does to make bare system calls more usable to applications -- and what the OS does to make information available as simple system calls. sys_getpid takes maybe 5 instructions in a 'message passing' safe os, but takes 1500 cycles in linux. Try to find the parent folders given just a file's fd or inode for instance... it's really annoying for no reason other than the system is designed in C and had to be made ridiculously simple because of that.

I mean here we're talking about people writing user-space drivers and filesystems and such for a systems with really really slow context switches -- compared to a kernel running typesafe code. People are doing this thing which is hundreds of times slower than a microkernel that runs a safe os, but speed is so important eigh? Come on.

Re:Performance

[iamacat]

Yes, in the same way as running a game or a video authoring application under a time-sharing operating system "drastically lacks in performance". In overwhelming majority of cases, it has been found that stability, ease of maintenance and convenience of using 3rd party libraries with non-trivial algorithms are well worth the not-so-drastic performance penalty. Besides, in userspace you can use pthreads to take advantage of multiple CPUs/cores in todays computers. Writing an explicitly multi-threaded kernel driver is not trivial.

Re:Performance

[BiggerIsBetter]

So graphic drivers as well as file system drivers and similar cannot use this API at the moment. Fuse and NTFS-3G seems to work pretty well for me, so I'm not entirely convinced by that statement.

Re:Performance

[Roydd McWilson]

That's what, 80,000 cycles plus? That's ridiculous. All to save some registers and load a new LDT?

Fo sho 80k cycles is a bitch, but what you screamin' 'bout loadin a new LDT?? Yeah it may happen an' all, but Linux don't give much'f a damn 'bout segments... a couple big 4giggers'll do. The real dope is at the page table... straight up CR3 swappin', and 'course the attendant TLB and cache thrashin' (yeah I know you don' gotta clearance it all out dudez).

Re:Performance

[Anonymous Coward]

Yes, work pretty well as in parts 1 and 2 of "Make it work, make it work well, make it work fast"
They may work, but use a ridiculous amount of CPU power if you're doing serious data transfers....

Re:Performance

[Roydd McWilson]

I mean here we're talking about people writing user-space drivers and filesystems and such for a systems with really really slow context switches -- compared to a kernel running typesafe code. People are doing this thing which is hundreds of times slower than a microkernel that runs a safe os, but speed is so important eigh? Come on.

Amen brotha, sing it!

Re:Performance

[cnvogel]

sys_getpid takes maybe 5 instructions in a 'message passing' safe os, but takes 1500 cycles in linux.

Sorry, but you are wrong. On a Pentium i586, 133 MHz (my "home router") in a loop of 4096 calls of getpid() I need 192 cycles for 4086 out of 4096 loop iterations.

rdtsc ### Read Timestamp Counter
mov %eax,%ebx ## store timestamp ctr
mov $0x14,%eax ## syscall 0x14 is getpid
int $0x80 ## execute syscall
mov %eax,0xffffffe4(%ebp) ## save result
rdtsc ### Read Timestamp Counter

If you only time "rdtsc, mov, rdtsc" it needs 13 cycles. I'd hardly call 179 cycles a big overhead, especially if you consider that the Pentium4 is supposed to have a faster "SYSENTER" instruction which the small pentium lacks. And I'll be very impressed if you show me any operating system that can do a getpid in 5 instructions if the information about the pid needs (let's say) dereferencing of 2 pointers....

Re:Performance

[init100]

Those are just translators that still use the in-kernel device drivers, that can use DMA.

Re:Performance

[xeoron]

With the new kernel scheduler and, now, the userland api, things are starting to get a lot more interesting...

Re:Performance

[TheRaven64]

So graphic drivers as well as file system drivers and similar cannot use this API at the moment Why would they need to, when we already have DRI and FUSE for these classes of driver?

Re:Performance

[TheRaven64]

x86 does not have a tagged TLB. This means that every context switch needs a full TLB flush, which results in a lot of TLB (and cache) churn. On something like SPARC, you just set the process ID register, and TLB entries belonging to other processes become invisible.

If you want to see a Microkernel done right, I'd suggest you look at Xen, by the way. It has shared memory and aynchronous notifications, and not much else. The reason microkernels typically suck performance-wise is that the designers tend to opt for a synchronous design, presumable believing that it's still 1980. That means you need an absolute minimum of two context switches (one there, one back) for every message, and typically four (via kernelspace both ways). An asynchronous design lets you just write messages into the a buffer (at no more cost than writing arguments to the stack), and performs only the context switches required to run the different processes. On an SMP system, you can have the components running completely in parallel.

Re:Performance

[TheRaven64]

Windows NT can do the equivalent of getpid much faster, because the top of the process's address space has a number of kernel data structures mapped into it (read only). In theory, this could be done in one instruction (load constant value). In practice, I believe they do it via a call to a DLL which does the lookup, so they can change the kernel data structures between versions. That would make the required instructions something like CALL, LOAD, PUSH, RET, POP, for a total of five.

By the way, the TSC is not necessarily a cycle counter. I don't know about your particular CPU, but the only guarantee it makes is that it's a counter which is always monotonic on a single core. It's usually incremented by a clock, but this may not be the CPU clock (it could be the external bus clock, with an extra increment whenever the instruction is used, to guarantee monotonicity, for example), so it might not be an accurate way of counting cycles.

Re:Performance

[cnvogel]

Windows NT can do the equivalent of getpid much faster, because the top of the process's address space has a number of kernel data structures mapped into it (read only).

To be honest, I don't care a bit how fast my operating system determines a process' pid, but rather took the getpid()-function as the prototype for the simplest possible syscall to test the minimal latency of calling any kernel function. That's also why I did not use getpid() library function directly, that function has the nasty habit of calling the kernel only once and caching the result from that moment on...

And still, 190 cycles is still much less than what you guessed linux would need (1500 cycles).

By the way, the TSC is not necessarily a cycle counter.

The intel architecture manual describes the TSC counters as ticking with the usual processor clock (the usual bus clock times multiplier) or with the maximum processor clock on core CPUs (where I think the multiplier might change or be different for different cores, I'm not sure on the last one). Nevertheless, on the machine I counted cycles for getpid() it's ticking nicely with the expected 133 MHz frequency, I just checked by counting the cycles a sleep(1) needs.

(Inte 64 and IA32 Architectures Software Developer's Manual, November 2006, Vol 3B, Page 18-37. I still can't believe that there are programmers on Intel hardware which are NOT regularly checking into this book ;-) ...)

Re:Performance

[Roydd McWilson]

x86 does not have a tagged TLB. This means that every context switch needs a full TLB flush, which results in a lot of TLB (and cache) churn.

Not necessar'ly. Ah ain't no CPU architect, but f'seebly you could fabricate a tag from tha current CR3 value an' maybe let the cache notify ya when yer assumptions gota hell. Wud this improve perf in real design? Fukc if I know!

Re:Performance

[TheRaven64]

In theory it would be possible. In practice, it would be hard. When an operating system does a context switch, it flushes the TLB. Imagine if you exit one process and then another user forks one. The operating system context switches out of the first one, and returns its page tables to its memory pool. It then re-uses the same page directory entry or the new process. This process then has some stale TLB entries and can access a load of pages it shouldn't be able to. This is the most obvious corner case, but there are a few others that are actually more likely to occur.

Intel and AMD have both added tagged TLBs to their next generation architectures, but they are primarily aimed at virtualisation. I know Intel changed the TLB semantics somewhat with the Core 2, but I don't know exactly what they changed.

Re:Performance

[Roydd McWilson]

Oh totally I dig whatcher sayin dude; I suppose the buddhist-like middle path shit'd be to offer high perf and compat modes at the flick of a flag.

Re:Performance

[cryptoluddite]

Your faith in the timestamp counter is disturbing. People don't generally program in assembly and they don't measure time using a counter or run programs on very old systems. On every machine I have tried this on, doing millions of sys_getpid calls (non-cached) measuring in real wallclock time on Athlon, Pentium 4, single core, dual core, etc it generally comes out to ~1200 cycles ... to read a single int from the kernel.

I suggest that if you retest this system using a much larger number of calls and measuring in real time you'll see a dramatically different result.

Re:Performance

[cnvogel]

Your faith in the timestamp counter is disturbing. People don't generally program in assembly and they don't measure time using a counter or run programs on very old systems. On every machine I have tried this on, doing millions of sys_getpid calls (non-cached) measuring in real wallclock time on Athlon, Pentium 4, single core, dual core, etc it generally comes out to ~1200 cycles ... to read a single int from the kernel.

Here you go (you can email me if you want the program source, but it's now reduced to a for()-loop, 10 million times, and inside that loop there is a getpid()):

rage ~ $ time ./cycles

real 0m11.858s
user 0m6.140s
sys 0m5.720s

11.858 / 1e7 * 133e6 is 157 cycles.

Maybe on your system there is some overhead, a SMP kernel needing locking or whatever strange thing, but on that pentium, I get this many cycles. And not 1500.

Re:Performance

[Anonymous Coward]

I think what must have happened is that when I last tried this the code was using int 80 rather than sysenter (probably from using an older diet libc). Reran the test rather than going by memory and I got:

Pentium D, 2992 mhz:

sysenter: 496.83
int 80: 996.92

For sysenter I used the normal linux vsyscall and for int 80 inline asm:

__asm__ ("int $0x80" : "=a" (rc) : "a" (20));

The int 80 jibes with my memory of ~1200, since calling a function and older processors should account for a few extra cycles over that ~1000. But you are right that an actual syscall will use sysenter and so will be much faster than what I was claiming. But in any case the exact timings are not very meaningful as many syscalls will cause a process to sleep, have over head to copy data in/out and from copying that data, and overhead from simple interfaces etc.

Take another example of getdents, this function is going to a lot of trouble to use virtual fs calls to format data into: inode + next_rec + length + name. Programs don't normally care about the inode, or the lengths (except to depack this format), then generally take the name and then call stat to look up each name. So for example on my system to do an ls on a folder with 100 entries not even counting the wasted time to collect and format data that's 50k cycles completely wasted. If the ls program is just printing names and a trailing "/" at the end why especially must it copy a whole 88 byte structure for each file just to access *one* field? Why does the kernel need a separate 4k/8k stack why can't it use the program's stack? etc.

In a typesafe OS each program can be recompiled to match the kernel object offsets so could access many kernel structures directly or through read-only objects. Getpid could literally be a "self->pid" statement that directly accesses the memory for a total of 2 instructions (load &self, load self+offset). Dirents could return a list of references to the actual file objects since lifetime and ownership are not necessarily so rigid and fixed. In practice most systems designed to run typesafe code set up partitions and do copies, but even here the extent and overhead of these is much less.

Look it's human nature to defend something they can't change. You can't make a safe kernel that runs the existing unsafe codebase effectively. So to change the status quo one would have to create a safe kernel that was equivalent in functionality to say linux and it would have to be better enough to get people to use it despite poorly running existing codes. IOW, we're stuck with this c-based monolithic crap and we'll be stuck with crappy userspace filesystems and drivers since that's the best we can do given that the kernel isn't going to change. This will probably continue until computers are so fast that the vast majority of what we use is in a language like javascript say where we can pull out the unsafe code without anybody noticing.

Good lord don't even mention including a virtual machine support in the linux kernel if you don't want to be the laughing stock -- never mind that even a simple one like neko could make things like inotify actually useful. If you start actually making a list, the number of limitations and compromises in modern systems entirely because of unsafe languages is astounding.

What would be really nice...

[Bonker]

would be a world where you didn't ever have to RECOM-FUCKING-PILE the kernel to install major drivers.

No, it's not that bad any more, especially in User-oriented distros like Ubuntu. There are quite a few user-space drivers out there, especially for non-hardware related tasks like filesystems (as opposed to disk IO). There are still times when, to get something to work properly, you simply have to recompile the kernel. This is especially true for 'nonstandard' hardware that likes direct IO, like disk-arrays.

Re:What would be really nice...

[laptop006]

You already don't.

Look at things like debian's module-assistant.

Re:What would be really nice...

[pembo13]

I thought all you need are the kernel headers and you just compile (not recompile) the module alone.

Re:What would be really nice...

[Anonymous Coward]

You don't know what you are talking about!
Drivers can be compiled as modules for many, many years already. And modules can be put in an initrd to load a driver for the root filesystem during boot.
So there is no need at all to recompile the kernel. Maybe you have been doing it all the time, but that is ignorance. Blame yourself, not Linux.

Re:What would be really nice...

[Alioth]

You've not needed to RECOM-FUCKING-PILE the kernel for a new driver for well over 10 years now... I think modules were added back in 1993 or so. The only people who've been recompiling kernels in the last decade are either (a) unaware of modules or (b) building a statically linked kernel for a niche app. Or perhaps some vendor was too clueless to supply a driver as a module.

Re:What would be really nice...

[Arkan]

> (...)'nonstandard' hardware that likes direct IO, like disk-arrays.
Which is, as far as I know, scarcely used in a small business situation, or even a home user one. And in this kind of situation, you have system administrators - I know, I'm one of those - who are PAID to do this kind of job.
Not that recompiling a kernel really requires high level expertise, mind you.

Anyway, isn't the solution to petition your favorite vendor to provide the relevant driver with a convenient licence so that it can be incorporated in the kernel?

--
Arkan

Re:What would be really nice...

[wellingj]

...or applying patches for the scheduler and what not...

Re:What would be really nice...

[level_headed_midwest]

The only reason that you would have to recompile the kernel to add major drivers would be if the default kernel didn't have the driver you needed compiled as a module. But that generally only happens with pretty uncommon hardware as most everything is compiled as a module in Linux kernels anymore. You might have to change your modprobe scripts to load the new hardware's modules at bootup, but that's about it. And if you have a new driver that's not in the kernel tree (like ATi/NVIDIA and VMware drivers), the worst you have to do is compile it against the kernel, not recompile the whole kernel.

There are other reasons one has to recompile a kernel, but drivers aren't generally one of them, unless you count moving from a single-core box to an SMP one and needing to enable SMP. But even that's rare as most distributors have only an SMP kernel and no UP kernel now.

I thought I read Uberspace

[TheRistoman]

So I immediately thought of a spaceship running Linux... I mean, could it really be otherwise?

Re:I thought I read Uberspace

[Romwell]

I was just about to ask if I'm the only one who read Uberspace Drive (which is sorta like Warp Drive, only cooler), but in spite of Slashdot instinct, I searched the thread first =) Pleeeeeeeeeasse mod parent up =)

What exactly are the API stability guarantees?

[Anonymous Coward]

A stable API is great because it means that code written against it will continue to work for future versions of the kernel.

Out of curiousity, what is the guarantee (or intention)? Is it expected that API won't change again for 2.6, or is it more "we're going to try really hard not to change it unless we have to" kind of thing?

Re:What exactly are the API stability guarantees?

[Anonymous Coward]

You're completely missing the point.

The Userspace-API of linux was and will probably continue to be ultrastable. With the right libc you can run a programm written for Linux0.99 on Linux2.6.22.

What is changing and will continue to change is the in-kernel-driver-API. So nothing new here.

The news: A driver API _in_Userspace_.

Capis?

Re:What exactly are the API stability guarantees?

[phantomlord]

Out of curiousity, what is the guarantee (or intention)? Is it expected that API won't change again for 2.6, or is it more "we're going to try really hard not to change it unless we have to" kind of thing? Given that Linus usually has a fit when someone breaks userspace (but generally doesn't mind breaking kernelspace, as long as the affected code is patched at the same time), I'd say it's going to be more along the lines of "we're going to try really hard not to change it unless we have to." Even then, it's typical to see an "emulate OSS devices under ALSA?" type option.

Finally...

[Statecraftsman]

The lack of a stable userspace driver api was that last thing stopping soccer moms and grandmothers from running Linux on the desktop.

My sarcasm is so extreme, I think what I said above may have actually been true.

Re:Finally...

[Verte]

Although your post is cute, you actually have a point. You can argue about how changes to the kernel affect performance, but otherwise they aren't likely to make a difference to the GNU/Linux experience. Maybe we should be actively pointing our developer friends away from romantic dreams of kernel hacking and on to more overlooked projects. Or even wine..

Re:Finally...

[zullnero]

Considering that the major blocker for the average person in regards to making the switch to Linux happens to be driver support, then yes, it could make it easier for "soccer moms and grandmothers". Of course, that should be pretty obvious from even the article summary.

Re:Finally...

[howlingmadhowie]

no, the major blocker is "it's not windows"

Re:Finally...

[Anonymous Coward]

Considering that the major blocker for the average person in regards to making the switch to Linux happens to be driver support no, the major blocker is "it's not windows" You're both right. It's easy to get Windows drivers for my hardware: download, click "install". On Linux, getting updated drivers means recompiling a kernel; grandma / soccer mom can't do that.

Re:Finally...

[howlingmadhowie]

on linux, getting updated drivers means clicking "update" when the GUI informs you that an update is available.

Re:Finally...

[EsbenMoseHansen]

Considering that the major blocker for the average person in regards to making the switch to Linux happens to be driver support no, the major blocker is "it's not windows" You're both right. It's easy to get Windows drivers for my hardware: download, click "install". On Linux, getting updated drivers means recompiling a kernel; grandma / soccer mom can't do that.

Do you really think that "soccer moms" are going to get "updated drivers" by either method, ever? What matters to them is: does it work out of the box? Linux is better than windows in that respect (better out-of-the-box-hardware-support), but again, that doesn't matter because the mother in question will certainly buy a box with the software already installed. So what really matters is the system, software included, that is actually sold to the customer. For that, the factors I can see matter are:

• Availability.
• Price
• Brand recognition
• Salesmen motivation.

From a practical viewpoint, the linux "update everything by a single click" (drivers included) is much more user friendly for the inexperienced than the windows "hunt the net for the newest updates for each component". But I sincerely doubt that moves many installation for the very-non-technical in significant any way.

Re:Finally...

[drinkypoo]

on linux, getting updated drivers means clicking "update" when the GUI informs you that an update is available.

I've had hardware that worked properly under one version of something not work under the next version of something, or work more poorly. I am forced to upgrade those drivers when I upgrade my kernel. Any of us with any experience has had hardware that worked better with older drivers. (And if you haven't, you aren't experienced, return to step 1.)

There ARE benefits to the model of driver support used with Linux. If your driver isn't actually in[cluded with] the kernel, though, it's all bad.

Re:Finally...

[tepples]

on linux, getting updated drivers means clicking "update" when the GUI informs you that an update is available. On Linux, how does the user cause the GUI to inform the user that a driver update is available?

Re:Finally...

[Trelane]

generally, notifications.

Re:Finally...

[tepples]

generally, notifications. What causes the notifications to appear? Which Google search terms should I be using?

Re:Finally...

[Trelane]

HAL, I believe. It should be noted that the infrastructure is there, but I don't believe that it's complete nor utilized for this purpose yet.

Re:Finally...

[howlingmadhowie]

on ubuntu (for example), when you log in, if you are connected to the internet, an "apt-get update" will be carried out in the background. if there are new versions of installed packages, an icon will appear informing you of this. this goes for the kernel as well.

Re:Finally...

[tepples]

on ubuntu (for example), when you log in, if you are connected to the internet, an "apt-get update" will be carried out in the background. Is this efficient over dial-up, or is Ubuntu squarely targeted to people who live within the reach of broadband?

if there are new versions of installed packages, an icon will appear informing you of this. But how do the new versions of installed packages get created, and how do driver packages for new kinds of hardware get created? Is Ubuntu designed only for installation on a purpose-built PC, or is it also designed for a "switch" installation on a paid-for machine that once ran (or still runs) Windows?

Re:Finally...

[howlingmadhowie]

it's not very efficient over dial-up (i should however mention a story about a friend of mine who has a windows pc with a umts card for the internet. his provider told him to update his software and offered a download to do so. 127MB. compared with that, the linux kernel is small). i'm not sure you'd say that ubuntu is targeted for users with broadband. it does however use a fast internet connection to provide a better user experience.

new versions of packages get created by the package maintainers. with ubuntu, a core team of maintainers compiles new versions of packages as soon as they see fit (for example, firefox 2.0.5 was ready about a day after it was announced (you must remember, no user has the rights to update firefox themselves, so this is best done using the package manager)). when it comes to drivers there are two distinct models. either the driver is part of the kernel tree, at which point the package maintainers for your distro will probably decide to include it in the standard kernel (at least as a module) because they like having kernels with the kitchen sink thrown in. the other possibility is that the driver isn't part of the standard kernel and has to be "linked to the kernel dynamically at runtime". this would be a standard driver with which you are familiar through windows. new versions of these get done whenever the developer sees fit. if you're using debian or ubuntu or one of the distributions with large online repositories, the maintainers of the distribution will probably also make a package available for your distribution, but maybe for the next full version and not for the current version.

ubuntu, just like all linux distributions supports exactly as much hardware as has been compiled for when the maintainers configured the kernel (plus some external modules). chances are, on a desktop computer pretty much everything will work, on a laptop you are more likely to have problems with some components. if you compile your own kernel, you can of course compile in support for everything from a digital watch up to big blue. the pc market does is however infested with NDAs and patents and copyrights which mean that some hardware can never be supported.

i hope this clarifies things a bit.

Re:Finally...

[Timmmm]

Yeah, *if* you know the name of the driver ('nvidia-glx-new' dontchaknow?) and *if* it's in the repository.

For example, how do install the eyetoy driver under linux? For windows I just search for 'eyetoy driver' and find this helpful page:

http://www.iplayplaystation.com/eyetoy-as-webcam/

Linux? Not a clue.

Re:Finally...

[howlingmadhowie]

bad example.

you probably already have the ov511 driver installed on your system. in other words, just plug the eyetoy in and see if it's recognised.

Re:Finally...

[PitaBred]

Well, if you really stretch your cranial capacity past it's single-digit-IQ capabilities, you'd search for "eyetoy driver linux" under google, and get this helpful page as the first result showing that it'll be available soon, in theory. My, that was hard, wasn't it?

Re:Finally...

[petermgreen]

with windows I buy a peice of hardware (I include things like scanners, printers, external storage etc) and it comes clearly marked on the box what versions of windows it will work with and if drivers are required they are included in the box and easy to install.

with linux if you are lucky the driver is just included, If not you are in for a world of hurt trying to get a driver that isn't part of the standard kernel and may be outdated installed.

Re:Finally...

[juhaz]

On Linux, how does the user cause the GUI to inform the user that a driver update is available?

By turning on his computer. Why on Earth would he actively need to do something for something as trivial as software updates?

Re:Finally...

[ccp]

Is this efficient over dial-up, or is Ubuntu squarely targeted to people who live within the reach of broadband?

I happen to live in backwards South America, but in the XXI century.
What is this dial-up you speak of?

Cheers,
CC

Re:Finally...

[tepples]

What is this dial-up you speak of? In the United States, dial-up is what people who can't afford urban real estate and who can't afford satellite Internet access have.

Re:Finally...

[tepples]

On Linux, how does the user cause the GUI to inform the user that a driver update is available? By turning on his computer. Why on Earth would he actively need to do something for something as trivial as software updates? Next question: What causes the updates to become available?

Re:Finally...

[ephemeralspecter]

I hate to sound like a doz fanboy, but vista can update drivers and software with "one click" (ish). It's a nice step in the generally right direction by microsoft, imo. (Granted, your SCSI scanner might not work in vista, but hey, it's just time to buy new hardware anyways, right?)

Re:Finally...

[ccp]

In the United States, dial-up is what people who can't afford urban real estate and who can't afford satellite Internet access have.

Here, you'd have to live in the boondocks in order to be unable to get at the very least ADSL. That would be towns with pop. 10K or less. I guess 5-10% of total population.
Of course, most people don't have the need or cannot afford the 25/30 U$S monthly, but the capability is there.

I didn't realize you were so far off as to broadband availability.

Cheers,
CC

Re:Finally...

[ccp]

I didn't realize you were so far off as to broadband availability.

Oops! I meant worse off.

Linus the pragmatist

[Zork the Almighty]

Maybe this path will ultimately bring proprietary drivers to Linux in force, but I think Linus has made the right decision. We should start looking for other ways to convince companies to write open, GPL drivers.

Re:Linus the pragmatist

[Alioth]

It's not just proprietary drivers, it's open source ones too, especially for niche hardware. You're never going to get your kernel driver accepted by the high priests of the Linux kernel team for a piece of hardware with half a dozen users, so you are doomed to rebuilding the module every time you do a yum update, and your distro has a new point version of a kernel. It really kills the usability of Linux when this happens.

Fortunately, for USB devices, this has existed for a while. (Indeed, there's little reason to write a kernel-land USB driver these days).

Re:Linus the pragmatist

[chromatic]

You're never going to get your kernel driver accepted by the high priests of the Linux kernel team for a piece of hardware with half a dozen users...

Greg Kroah-Hartman's OLS 2006 Keynote says "We have drivers that I know have only one user, as there was only one piece of hardware ever made for it."

Here's a better idea

[Anonymous Coward]

Design an API that will be transparent to the execution context. Drivers that are proven to be stable over time can be moved from user space to kernel space at the flick of a root command (no re-compilation of driver code or adaptation required).

Re:Here's a better idea

[wellingj]

No one is stopping you from implementing it yourself and submitting it to the main line.

Re:Here's a better idea

[tepples]

No one is stopping you from implementing it yourself and submitting it to the main line. Not even the reputations of maintainers called "the high priests of the Linux kernel team" by Alioth, who are likely to point out what they consider as fundamental problems with the concept behind a given patch, reject the patch, and claim to plan to reject any similar patch? What is the point of making a patch to the kernel if 1. it doesn't get in and 2. you are not willing to devote a percentage of the rest of your life to single-handedly modifying your patch to match changes to the latest kernel?

Re:Here's a better idea

[wellingj]

Not even the reputations of maintainers called "the high priests of the Linux kernel team" by Alioth, who are likely to point out what they consider as fundamental problems with the concept behind a given patch, reject the patch, and claim to plan to reject any similar patch?

I never said that the kernel maintainers would accept said patch, I merely meant to point out that if it was a grand idea(referring to parent and *not* UIO) that it would be accepted into the mainline based on its technical merits. I was not opposing the UIO patch in any way shape or form. I think you misunderstood me. I'm all for UIO. Especially since I'm trying to persuade my current employer to look into embedded Linux as a OS solution since we are a smaller integration company with limited resources to develop our own OS.

Re:Here's a better idea

[PitaBred]

Those "high priests" also tend to know a hell of a lot more about kernels in general and the Linux kernel specifically than a random layperson, or even a highly experienced coder. It would do you good to learn from them. Perhaps instead of bull-doggedly trying to push your patch, perhaps you should figure out what they specifically objected to (they don't randomly object to all patches, as the kernel does keep being developed and having patches applied), figure out why, and fix it. Either by explaining to them (with evidence!) why they are wrong, and you better be DAMN sure you're right, or more likely by fixing the problems with you patch. Do you expect the engineers at Ferrari to take your suggestion on what cam to put in their engine, even if you're a fast car enthusiast? Why would you think the Linux kernel keepers are any less elite in their skills and knowledge?

Like QNX, although not as clean

[Animats]

QNX has had user space drivers along somewhat similar lines for many years. In QNX, all the drivers are in user space, which makes for a much smaller kernel. Here's a simplified article on QNX driver writing.

The Linux approach has the problem that Linux doesn't have the message passing primitives that QNX does. So there's a special purpose mechanism to hook up these new user-space drivers to the I/O system calls. In QNX, "open", "close", "read", and "write" are actually C library functions that call MsgSend to do the work. (System V IPC isn't really suitable; it's asynchronous, which means a few extra scheduler events for every message pass when you try to use it for something that works like a subroutine call. Long story.)

Unfortunately, on x86 hardware, you can't protect the system from a user level driver and still give the driver direct hardware access. IBM VM mainframes get this right, but x86 does not. On the other hand, you can have channel drivers for the various types of x86 channels (SCSI, FireWire, USB, etc.) and make other drivers work through them.

User-level drivers cost you at least one extra memory copy of the data. That's not too bad in practice. I did a FireWire video camera driver for QNX, and when transmitting 640x480 24 bit images at 15fps, it took about 3% of a Pentium 4 CPU.

Re:Like QNX, although not as clean

[wellingj]

http://www.osadl.org/UIO.uio.0.html

They impression that I get is that this is in order to use SOC's more effectively. Things like using PWM and GPIO on SOC's aren't that portable across different brands of micros. This would be an easy way for all the SOC chip makers (Freescale, Atmel, Renesas, Marvell, ect...) to create the bottom level of the driver and use the same userspace driver for embedded developers. this will still give the developers enough leway to mess with things if they need to.
I could be totally off though...

Embrace, Extend, Extinguish

[DriftingDutchman]

If this brings us closer to using (possibly unreliable) windows drivers, a major reason for using windows will be gone.

Poor compromise

[yvajj]

I wonder if this compromise is worth it. I'd much rather have stable kernel drivers than unstable userspace drivers.

If a driver is buggy and in userspace, its possible that the system could recover from the error, however you could still end up in some unstable state that would potentially end up requiring a reboot (depending on the driver in question).

Also, there is a higher cost of running a driver in userspace (ring 3) than kernel space (ring 0). As mentioned by the article, high traffic drivers (requiring DMA) are not supported.

The reasoning for this seems to be due to unstable proprietary kernel drivers. IMO, the solution to solving this problem is driver signing and certification. Don't use a driver unless its been signed and certified.

Re:Poor compromise

[Solra Bizna]

The reasoning for this seems to be due to unstable proprietary kernel drivers.

What about unstable open source kernel drivers?

-:sigma.SB (who went through over 60 reboots trying to get non-crashing 3D on his iBook's Rage 128 before finally giving up)

Re:Poor compromise

[gr8dude]

end up in some unstable state that would potentially end up requiring a reboot

Isn't this the most important thing about separating the kernel from everything else - that no matter what happens in userland, the rest of the system remains unstable?

Can you describe a scenario in which the system can enter an unstable state?

Re:Poor compromise

[yvajj]

If the driver in question is one that is critical to the running of the system (video, HD, KB etc), then its possible the user will not be able to interact with the system, thus requiring a reboot.

There is an inherent difference between a driver and an application. For the most part, most applications are not required for the running of the system.

High time!

[iamacat]

Just because some code controls a piece of hardware doesn't mean that a runaway pointer in it should cause a panic or even corrupt files by messing up filesystem buffers. This will also enable device drivers to make use of all available userspace libraries, with sophisticated algorithms that would never be used if all code had to be written from scratch and non-pagable.

Vista already has this (not trolling, read on)

[AlphaWolf_HK]

FWIW, not trying to troll, but thought I would point out that this feature is one of Vista's improvements over XP, and simultaneously the primary reason why Vista's compatibility isn't that great right now, and thus the primary reason why many people don't switch to Vista yet. Most of the hardware vendors have to make big changes to their drivers in order to accommodate this, especially nvidia who has to make about 4 different user space drivers (one for d3d, one for opengl, and an SLI version of both of those.) This is a good thing to have for both security and stability reasons, and I was waiting for when somebody would add this to the Linux kernel.

Linux has the advantage in that with Linux you can use both the old "kernel only" drivers, and the user space drivers at the same time. Vista could have done this as well, however Microsoft felt that if they allowed this to happen, then most hardware vendors would be lazy and continue to use their old kernel mode drivers, thus defeating the purpose. And to be honest, I agree with them. Linux doesn't need this on the other hand, as eventually somebody who is interested will make these kinds of changes to all of the open source drivers anyways as needed, which can't really happen because most windows drivers are binary only, so Linux can more or less take the "phased change" approach.

Disclaimer: I use both Vista and Linux (gentoo is my preferred distribution,) and am not afraid to say that I don't hate either of them, and rather like both of them.

Re:Vista already has this (not trolling, read on)

[Anonymous Coward]

You're half right.

Vista has partially user-space drivers for graphics, where the majority of the driver is in user space, and the kernel-mode component just allows communication between the driver and the hardware. Linux already has a similar architecture, as does MacOS X.

Second, it has user-space USB drivers. Which Linux and MacOS X have both had for ages.

It also has user-space printer drivers, which is no big deal - printer drivers hae been user-space only for years on most operating systems.

No other driver is user-space. They're all still in the kernel. They have modified the API and ABI for a lot of them, particularly sound (by removing all hardware acceleration) and network (because it interacts with the newer network stack).

Re:Vista already has this (not trolling, read on)

[wwahammy]

Actually it was there before Vista. Windows Media Player 11 came with the first version of the userspace driver framework. I think its used for media players that sync with WMP.

My understanding was that Microsoft recommended companies move to userspace not that it was required. To be fair though, I know very little about WDDM so they might have different requirements.

When I read the headline, the first thing I couldn't help but think was if the roles were reversed there would be hundreds of people saying "Good to hear you got something Linux had for a year already." Good ideas are good ideas. Why can't people just be happy when their ideas are recognized as good by others?

Re:Vista already has this (not trolling, read on)

[AlphaWolf_HK]

When I read the headline, the first thing I couldn't help but think was if the roles were reversed there would be hundreds of people saying "Good to hear you got something Linux had for a year already." Good ideas are good ideas. Why can't people just be happy when their ideas are recognized as good by others? Well, this is slashdot. This is the reason I had to emphasize heavily that I am not trying to troll here. I've had it happen more than once where I've said something positive about Microsoft and immediately get modded down as trolling.

Re:Vista already has this (not trolling, read on)

[wwahammy]

And its a shame because there are positive things happening at Microsoft and there are negative things just like there are positive and negative things in the Linux world and so forth. Open-source developers, like a scientist, need to put aside egos and see what works and what doesn't, no matter who came up with it.

Re:Vista already has this (not trolling, read on)

[sgbett]

Disclaimer: I use both Vista and Linux (gentoo is my preferred distribution,) and am not afraid to say that I don't hate either of them, and rather like both of them

I am in a similarly shaped boat. I've come to the belief that if one is not forced to use windows, it doesn't seem quite as bad when you do drop into a vm to perform one of the few remaining 'windows only' tasks. It's taken quite some time for the resentment to wane though.

OTOH as a web developer, I think my the disdain and hatred of IE is here to stay, but that's for another discussion!

Re:Vista already has this (not trolling, read on)

[AlphaWolf_HK]

And its a shame because there are positive things happening at Microsoft and there are negative things just like there are positive and negative things in the Linux world and so forth. Open-source developers, like a scientist, need to put aside egos and see what works and what doesn't, no matter who came up with it.

I agree. This is why I tend to look at Open Source the same way Linus Torvalds does instead of Richard Stallman. Stallman is more interested in communism, and generally believes that the ownership of anything, including software, is reprehensible. Torvalds is more interested in being practical. The kernel is more like a standard, like USB for example, that numerous companies and individuals can invest in and develop and still capitalize off of, because it allows for the interoperability of their products, or just allows them a highly scalable platform that can work on top of any hardware they sell.

But some software, like games for example, is best owned and sold for a profit, or else the entire industry wouldn't really be practical, and wouldn't be nearly as advanced as it is today had it not been for that. And that is the beauty of capitalism, is that if somebody isn't motivated to do it on their own, you can always pay them to do it.

Re:Vista already has this (not trolling, read on)

[smoker2]

Open-source developers, like a scientist, need to put aside egos and see what works and what doesn't, no matter who came up with it.

Open source devs usually do, but then they get blamed for cloning proprietary software. That's without mentioning the M$ patent troll, who jumps on people for implementing new ideas "no matter who came up with it" !

Re:Vista already has this (not trolling, read on)

[Anonymous Coward]

Please name A SINGLE QUOTE where Stallman has EVER SAID that he finds ownership reprehensible, that supports your nearly libellous statement.

Stallman finds the pretention of idea ownership reprehensible. And he is absolutely right in that sense.

Re:Vista already has this (not trolling, read on)

[cbhacking]

Vista does actually support many kernel-mode drivers using Compatibility Mode installers or modified INF files, so I am fairly sure that the Vista kernel still supports Kernel-only drivers. Besides, as with this Linux driver model, Vista's WDDM drivers and such still need a bit of kernel-mode code since, due to the architecture of the x86, you can't get direct hardware access with protected (user-mode) software. The idea is that the kernel code can be minimal and hopefully bug-free, and there is an API to allow the userland driver to access the kernel-mode shim.

Re:Damnit...

[Ohreally_factor]

I think someone needs a nap. =)

Not high performance

[eclectro]

From TFA there is no DMA access to kernelspace. So other than keyboards and mice I don't see how this can be practical for anything, other than embedded applications as the article alludes to.

Re:Not high performance

[Tony Hoyle]

USB drivers for example. There's no reason for anything using USB to be in kernel space - it just doesn't need the performance.

Ditto for filesystem drivers, although performance matters there - you'd have to design the driver API to minimise context switching.

I don't think anyone's expecting userspace IDE or graphics drivers.

Re:Not high performance

[TheRaven64]

Safe DMA will be possible in the relatively near future. Modern systems are starting to include an IOMMU, which makes this simpler; you simply set up a mapping so the device can only write to or read from the process's address space, and then it can do any DMA it wants safely. Current AMD chips include something called the 'Device Exclusion Vector'. This isn't a full IOMMU, since it doesn't handle translation, but it does do protection. You can tell the DMA controller that the device is only allowed to access a certain block of memory, and DMAs will fail if they write outside this area. The userspace driver would still need to know about machine addresses, rather than vertical addresses. I would probably do this by having a special process type for drivers that had a 1:1 virtual to physical address mapping, and just had holes in its address space where the kernel and other processes were living. The process could just walk its own page tables to do this, but it would be more expensive.

It would be nice to get a stable and usable userspace driver API, since then other operating systems could use it. DRI has done a lot for getting 3D supported across *NIX variants; the Linux and FreeBSD drivers are almost identical, and just need a slightly different kernel module which handles the very low-level parts.

Re:Not high performance

[tepples]

There's no reason for anything using USB to be in kernel space - it just doesn't need the performance. Care to back this up? Hi-Speed USB is a 480 Mbps bus; that's faster than 100BASE-TX Ethernet and on par with FireWire.

Re:Not high performance

[drinkypoo]

Care to back this up? Hi-Speed USB is a 480 Mbps bus; that's faster than 100BASE-TX Ethernet and on par with FireWire.

The primary difference in performance between a user space driver and a kernel space one is not one of overall performance but one of latency. USB is crap anyway, I doubt you would notice a difference. (and USB2 never actually produces real-world performance even all that close to the kind of speed you're talking about, although any $5 IEEE1394 card will very closely approach its theoretical maximum if you have fast enough peripherals. If I had only two computers, I would network them via firewire.

Re:Not high performance

[Anonymous Coward]

> The primary difference in performance between a user space driver and a kernel space one is not one of overall performance but one of latency.

Oh dear.

Did you bother reading the article? or even the reply to the comment earlier?
Here's some OS 101: The processor does not handle data-intensive transfers. While the processor is busy running instructions from the cache the bus is free to be used for data transfer. That's called DMA, direct memory access. That means that the data is passing through the bus directly to memory using a dma controller. If there is no dma access then for each and every memory address you need the cpu to read it, store it in a register and then write it in memory.

Thus, the current patch can not be used for intensive data transfer.

Re:Not high performance

[networkBoy]

Also worthy to note,
USB is framed data and half duplex, while firewire (IIRC) is streamed and full duplex.
I implemented a 4 way mesh in fire wire (4 PCs each with one 4 port firewire NIC) It rocked. Now I have GigE, but still it was awesome, full non-blocking access from any PC to any PC.
-nB

Re:Damnit...

[moro_666]

2.6.20 ? dude !!!

I know i'm hopelessy outdated and my machine shows:

martin@hope ~ $ uname -a
Linux hope 2.6.21-gentoo-r4 #1 Sat Jul 21 22:18:42 EEST 2007 i686 AMD Turion(tm) 64 Mobile Technology MT-30 AuthenticAMD GNU/Linux

Remove that gentoo notice quickly from your slashdot sig. A man using kernel 0.0.02 versions old is a stable version pimp not a gentoo roller... :p

As for the article :D
  Userspace drivers are not really a new groundbreaking idea now are they :D The lists are full of different proposals and attempts over different times, but it's really nice to see that this thing finally got rolling, this may open a lot of closed-source drivers for usage for linux people (a lot of those fancy windows toys).

  Thumbs up Linus ;)

microkernel

[jb.cancer]

well i remember Linus comparing microkernels to 'masturbating' sometime back. It seems as h/w continues to grow in power and several other factors contributing, pushing more stuff to userspace will now look a better idea after all.

Re:microkernel

[diego.viola]

Yeah I hope to see this in the future, a modern Linux micro-kernel with all the cool features and message-passing.

Useless API, for simple drivers only

[kscguru]

Maybe I'm unique in that I not only RTFA, but browsed the patches themselves.

Which led me to the conclusion that this patch set is worthless. It allows remapping of memory-mapped I/Os to a userspace app, and allows a thread to "wait" on an interrupt. Both are nice ideas, and it would be very easy to implement a nice serial port driver with the new APIs. (As any kernel hacker knows, serial port is one of the simplest device drivers; it's easy.)

The new API is completely useless for binary-only drivers. I/Os / IRQs are enough for extremely simple devices - these are, after all, the primitives for talking to hardware. But if this were all a driver needed, don't you think Nvidia / ATI would have used this model for shim drivers a long time ago? Simple things like DMA and PCI configuration access are not present - but to be fair, those are implementable with these primitives. Reality check: real world drivers are a lot more complicated. What is impossible is fast thread switching, kernel synchronization primitives, access to the network stack (wireless!), ring-0 CPU instructions, real-time timing access, and the huge reduction in context switches / cache flushes that comes from running within the kernel (moving code to user-mode increases latency by a factor of 3, roughly). Kiss the lag-free desktop goodbye as hard drive latency skyrockets, watch your 3D framerate drop by 70%, see your webcam stutter into unusability.

The kinds of drivers this API can support are the simplistic ones, the kind that are already GPLed and are already in the kernel, the 80% of devices in this world Linux has always had good support for. The kinds of drivers this API cannot support are 3D graphics, high-performance disk or networking, wireless networking, latency-sensitive USB or Firewire, the virtual devices (VMware, KVM, Xen, even /dev/tty) - notice that most of the devices Linux supports poorly (and all the common binary-only drivers) fall into this list.

To be fair, the official (e.g. from Linus) announcements I've seen only claim this interface is useful for embedded devices (which tend to code for a specific kernel, and not get updated). No official announcement claims the new API will help binary-only drivers. It's just the OSS-zealot crowd making unwarranted assumptions. Yes, this is the bad news: the stable userspace driver API will do nothing to solve binary-only driver dilemmas. Sorry.

Re:Useless API, for simple drivers only

[suv4x4]

What is impossible is fast thread switching, kernel synchronization primitives, access to the network stack (wireless!), ring-0 CPU instructions, real-time timing access, and the huge reduction in context switches / cache flushes that comes from running within the kernel (moving code to user-mode increases latency by a factor of 3, roughly). Kiss the lag-free desktop goodbye as hard drive latency skyrockets, watch your 3D framerate drop by 70%, see your webcam stutter into unusability.

Nice rant there. Let me summarize it:

"What is impossible in user space driver is kernel space features".

No shit. That's the point of a user-space driver. If you give a user-space app access to ring-0, it's no longer user-space. Or did you imagine there's some sort of unwet water that the stupid developers of the kernel keep missing.

The user-space driver is not set to replace all kernel mode drivers. Just like Vista, it's set to replace *some* of them, for example USB devices with low traffic. It's not a solution from heaven, it's just a reduction of fail-prone pieces that lurk in your system.

If you RTFA you probably had to read the summary as well where it's said user-space drivers aren't suitable for high-performance gear such as graphics cards.

Re:Useless API, for simple drivers only

[wellingj]

But it does help embedded developers who need access to an SOC's hardware like PWM and GPIO and A2D.
A lot of people really are missing the point here that this patch really doesn't do much for x86, but
does great things for SuperH PPC and ARM.

Re:Useless API, for simple drivers only

[kscguru]

I read the article and understand it perfectly well - we're making exactly the same point:

"What is impossible in user space driver is kernel space features". Alas, 40% of the posts in this discussion fail to realize that the binary-only drivers people WANT to see (3D gfx, wireless) are necessarily kernel-space, and are already anticipating Nvidia/ATI non-kernel drivers. Ha.

The stable user driver API can replace the drivers that were already GPL-able (because they do nothing IP-worthy) but aren't yet. It won't do anything for you or I or anyone outside the embedded market.

Re:Useless API, for simple drivers only

[Chris Snook]

In the embedded world, most of the interesting hardware you're controlling is attached through serial or serial-like interfaces. That's precisely why this patchset is worthwhile.

Re:Useless API, for simple drivers only

[njchick]

Actually, wireless drivers may work, but they will need to use the userspace end of the network, rather than the kernel side. In other words, some tunnel device would have to be created to feed the received data to and to get the data to be sent.

Re:Useless API, for simple drivers only

[cbhacking]

Worth mentioning here that Vista DID manage to move the video drivers to userland with only a minimal kernel-mode shim and an API for the userland driver. I'm not a Windows driver dev, let alone one who understands the new WDDM drivers, but as a gamer I can tell you the framerate has barely dropped - a few percent, which I can live with in exchange for system stability.

Re:Useless API, for simple drivers only

[Anonymous Coward]

"If you RTFA you probably had to read the summary as well where it's said user-space drivers aren't suitable for high-performance gear such as graphics cards." - by suv4x4 (956391) on Sunday July 22, @05:58AM (#19944545)

Which is what many of MS' key engineers on the NT dev team concluded, which allegedly ALMOST drove Mr. Dave Cutler (NT-based OS architect, who came from DEC, hence the VMS like design of NT-based OS) to quit Microsoft during the NT 3.51 to NT 4.0 transition... how?

I.E.-> When the decision was made to move the Graphics drivers from usermode/Ring 3/RPL3, into Ring 0/RPL 0 levels of operation, instead (GDI/User).

This apparently "ticked off" Mr. Cutler!

And, were I he @ that time? I'd have agreed, & did...

(Mainly, because he was RIGHT in 1 regard: It COULD introduce potential possible OS-wide instability, if severe enough flaws surfaced in Ring 0/RPL 0 levels of operations in said drivers (whereas, in NT 3.51 & below, video ran out of usermode/RPL3/Ring 3 code operations privelege levels, & if it collapsed? The OS would not 'fall down', & it could be restarted)).

DirectX & gaming were the reasons for this movement of video driver code into Kernelspace/OS space/Ring 0/RPL 0 levels of operations in fact/iirc (greater speed of operations via DirectX (to the hardware), less copies of data used, etc.)...

Funny though - lately?

Well, upon my reading more & more of HOW the new video subsystems work in VISTA, via DirectX, even in Explorer shell std. operations on the desktop?

It seems that MS has 'taken a reverse' & moved them BACK into userland mode code, more-or-less, via the use of DirectX in the new desktop shell interface "avalon"/Windows Presentation Foundation (WPF, DirectX being stub in RPL0/Ring 0 priveleged operations is here iirc)...

Userland code = good for stability, & from what I've been seeing on VISTA? NOT BAD, even for speed too (yes, not quite as fast as XP was on gaming, YET, on current drivers, but NOT that much slower either (10% diff., MAYBE?)).

APK

P.S.=> The more things change? THE MORE THEY GO BACK TO BEING THE SAME, if not eventually... lol! If I am wrong on ANY of the above?? Please - feel free to correct me on BOTH the historical data, &/or the technical data as well that came after it (I could be wrong here, not a device driver coder, but more of the MIS/IS/IT variety on the job typically/historically for me)... apk

Sorry not for MS Windows or OS X

[mrnick]

Since this is GPL then neither MS or Apple would dare touch it. If it was BSD then it might be possible that Apple might adopt it but they are not going to put something into their kernel that they don't own. The same goes for MS with the added difficulty of their operating system not being POSIX compliant.

This is why I am prefer BSD license over GPL. Though, I am sure the majority of the readers on here would disagree with me. Anytime I look at open software I always check if there is a BSD licensed equivalent as compared to GPL. Just in case I want to develop it into a commercial application and all. That way I don't have to distribute a license that passes rights onto the users. I can simply take the BSD license version make my modifications and slap a (C) on it. I know the GPL advocates would argue that is what makes GPL good, keeping people like me from doing just that but Apple and MS are people like me. That is why Darwin was derived from BSD not because they were so hot on the Mach kernel but because of it's license. If MS ever goes to a POSIX based UNIX type OS with a Windows GUI, just like Apple did, they would do the same thing but they wouldn't be nice enough to maintain an open source version like Apple has done with Darwin.

My 2 cents and change!

Nick Powers

Re:Sorry not for MS Windows or OS X

[Roydd McWilson]

If MS ever goes to a POSIX based UNIX type OS with a Windows GUI, just like Apple did, they would do the same thing but they wouldn't be nice enough to maintain an open source version like Apple has done with Darwin.

I don' see the ol' em-dollarsign pullin' that kinda shit veritably soon. They got a lot invested inta vista architectrally, and honestly now, deep down it ain't any worse than unix... it's mostly a matter of dev process suckage, which'd soon enough infect any other code base. But heyo ya know what? Them microfuckers do contribute to at least one total bona fide community open source project: GHC!! No kiddin, check out the site maint's email addr.

Re:Sorry not for MS Windows or OS X

[that this is not und]

If MS ever goes to a POSIX based UNIX type OS with a Windows GUI,

POSIX is an api layer. And there is a fairly robust POSIX api readily available for the NT kernel beneath Windows. It can plug in and run in parallel with the Win32 api layer. You can even download it for free. It's presently called Services for UNIX and formerly was called Interix. And Interix was a fully compliant POSIX layer.

Services For Unix even includes the GCC and the gnu toolchain bundled with it.

This POSIX layer is much more than the 'bare minimum' skeleton layer that Microsoft created themselves back in the NT 3 days for 'compliance' purposes. Interix was developed by a non-Microsoft entity (Softway Systems) who had a source license to the NT kernel for that purpose.

Re:Sorry not for MS Windows or OS X

[Tony Hoyle]

Services For Unix even includes the GCC and the gnu toolchain bundled with it.

Actually it doesn't. Vista includes the basic core, but to get any actually commands you have to go to the interix site and download them one by one and it takes bloody ages as there's no installer.

I tried it for a little while and went straight back to cygwin, which installs in minutes, runs a better (SFU has some really wierd interactions with the command shell.. the shell returns immediately instead of waiting for the command, plus it has hopelessly broken cr/lf handling) and is better tested.

Re:Sorry not for MS Windows or OS X

[SanityInAnarchy]

This is why I am prefer BSD license over GPL.

This is why I am prefer people who bother to learn English grammar.

Since this is GPL then neither MS or Apple would dare touch it.

I'm not sure they have to. For example, FUSE, an API for developing a filesystem in userspace, is GPL'd in its entirety, except for the library, which is LGPL'd. There is a Mac port, and the Mac kernel part is BSD licensed -- but the rest of it is probably the same GPL'd code. There's also talk of a Windows port, though I don't see anything about its status.

Anytime I look at open software I always check if there is a BSD licensed equivalent as compared to GPL. Just in case I want to develop it into a commercial application and all.

That's fine. I prefer to GPL my stuff. That way, I can always turn it into a commercial application, but you can't.

Can you give me one good reason why I should give you code for free, that you can then turn around and sell, without paying me a dime?

I know the GPL advocates would argue that is what makes GPL good, keeping people like me from doing just that but Apple and MS are people like me.

Again: Can you give me one good reason why I should give my code to Apple and MS for free, with no guarantee of anything in return?

That is why Darwin was derived from BSD not because they were so hot on the Mach kernel but because of it's license.

There are large parts of Webkit (Safari's rendering engine) that are GPL'd.

Now, you may be right -- if they did anticipate having to lock it down the way they do now. But do you really think it would be a serious problem for them if they were on an open kernel?

Here's a hint: Oracle doesn't. Oracle sells all of their products for Linux now. And because of the GPL, every time they have to go in and make a change to the kernel to better support their database, we get it back. If it weren't for GPL, we might not have, for example, ocfs2.

If MS ever goes to a POSIX based UNIX type OS with a Windows GUI, just like Apple did, they would do the same thing but they wouldn't be nice enough to maintain an open source version like Apple has done with Darwin.

This is your argument for BSD -- that MS would use it and not maintain an open source version? How is this any better than MS writing their own damned code, just like everyone else?

And just a little FYI -- Apple hasn't been particularly good at maintaining an open version of Darwin, and I'm fairly sure the rest of the Mac OS cannot be run on any Darwin except one they've compiled and signed themselves. That's not "open", that's tivo-ized to hell.

Ok, I get that you like BSD -- you like to freeload. And I get that BSD is great for MS and Apple, and everyone else who wants to freeload, or who has a legal department larger than some countries telling them that GPL is dangerous. I still don't see a single reason that I'd want to prefer a BSD license for my code over the GPL.

The only time I'd even consider it is if I was releasing the same code in a proprietary product, but that's what we have dual-licensing for.

Re:Sorry not for MS Windows or OS X

[TheRaven64]

Since this is GPL then neither MS or Apple would dare touch it. If it was BSD then it might be possible that Apple might adopt it but they are not going to put something into their kernel that they don't own. You can't copyright an interface (although you can copyright the documentation of the interface. See POSIX). To make this work on a different kernel, you probably couldn't re-use much of the code anyway, so it's not much of a problem. You'd just re-write the kernel component, and share the userspace part. Since the userspace part only depends on stuff shipped with the OS, it is subject to one of the GPL exemptions. Take a look at how DRI works. You have the DRM (Direct Rendering Module) part, which is a small kernel-space interface between the hardware and the userspace component, and is kernel-specific. The Linux modules are GPL'd, the FreeBSD ones are BSDL'd and the cross-platform code is generally MIT-licensed.

Apple might implement this, but if it becomes popular I would be less surprised if Amit Singh did an XNU implementation than Apple (he did the FUSE implementation, and knows far more about XNU than any human ought to). Apple already have a fairly nice driver framework in the form of IOKit. It would be nice to see IOKit ported to other platforms, but that would be a lot of work.

Re:Sorry not for MS Windows or OS X

[Vexorian]

If it was BSD then it might be possible that Apple might adopt it

I have located a typo in your post, you meant fork.

Re:Sorry not for MS Windows or OS X

[drinkypoo]

Can you give me one good reason why I should give you code for free, that you can then turn around and sell, without paying me a dime?

That's an easy one - when it's more important to you that the world use your implementation than that you get credit and/or other rewards for it.

Examples include the BSD TCP/IP stack, which was rumored to have been incorporated into Windows in, I believe, Windows 2000. It's quite believable because at this time Windows' stack became much faster and more mature, basically overnight. Vista, as you may know, has an all-new stack in which Microsoft reproduced several bugs from antiquity (Vista RC was susceptible, for example, to the LAND DOS attack. Just pathetic. But that's what you expect from Microsoft.

Basically, the BSD license is used for altruistic releases by people who don't believe all software needs to be Free (-as-in-GPL.) Whereas the GPL license is used by people who believe that it does.

In summary, there is no reason why YOU should be BSD-licensing. But there's ample reasons for others to do so.

Re:Sorry not for MS Windows or OS X

[Anonymous Coward]

Jesus fucking christ, dude; that gets really old, really quickly. If you talk like that in real life, that's one thing, but typing like that is just totally idiotic.

Re:Sorry not for MS Windows or OS X

[that this is not und]

Cygwin DEFINITELY is not a POSIX subsystem. It's just a kludge of Win32 DLLs that rides on top of the Win32 subsystem.

You see, the creators of Cygwin did not license the NT kernel source.

Microsoft has now successfully crippled Interix, in the way that you describe. It didn't used to be like that. Because Microsoft didn't used to own the product. In fact, the head of Softway Systems at one point produced an 'open letter to the Open Source Community' asking if OSS wanted to embrace Interix. People ignored him, the value of the company continued to plummet, and Microsoft bought Softway Systems.

My original point was that POSIX is just an api layer, which hasn't been refuted.

Re:Sorry not for MS Windows or OS X

[SanityInAnarchy]

Basically, the BSD license is used for altruistic releases by people who don't believe all software needs to be Free (-as-in-GPL.) Whereas the GPL license is used by people who believe that it does.

Oh, bullshit. I don't believe all software should be Free. I just believe that I should get something for my work.

I don't believe that makes it any less altruistic, either. After all, Microsoft could just as easily have used a GPL'd network stack, they'd just have to open up their kernel. Would that be so bad?

In any case, I do believe that software which is free should remain free, because fragmentation is bad. The BSD world is filled with examples of proprietary forks which made a few improvements and went nowhere, and yet, due to licensing restrictions, we can't have those improvements. In many cases, the source code for them may not even exist anymore. At least GPL software never has to die, as long as someone cares about maintaining it.

That's an easy one - when it's more important to you that the world use your implementation than that you get credit and/or other rewards for it.

Yeah, I can see people doing that. It's just not me.

Basically, if Microsoft wants me to write them a network stack, they should hire me. Otherwise, I'm basically like the guy who invented optical media. Sure, I might be proud to see CDs and DVDs everywhere, but someone got rich off that invention, and it wasn't me.

As for preferring to start with software written under one license or another, you might take a look at the Compiz and Beryl projects. Beryl was a fork of Compiz, started because the Compiz team was being so anal about the quality of plugins they were accepting that they were missing out on a lot of cool stuff.

Recently, there's been talk of merging the two projects again. There's only one problem: Compiz is BSD, Beryl is GPL. It's basically as bad as a proprietary fork, as long as Compiz insists on staying with a BSD license -- Beryl can take improvements from Compiz, but not the other way around. Ironically, this is exactly the kind of situation the GPL is designed to prevent -- if Beryl had been proprietary, there might have been similar licensing problems (large corporations like restrictive licenses and NDAs), and we might not even have been able to see the Beryl code.

So, it's not even so much that I'm worried about corporations freeloading off me, though I certainly have no inclination to make it easier for them. The reason I would actually care enough to choose GPL is that it ensures that all improvements make it back into the open version, and I'd argue that even improves the quality of the GPL version when compared to a BSD version.

Re:Sorry not for MS Windows or OS X

[Roydd McWilson]

hahaha

Re:Sorry not for MS Windows or OS X

[FireFury03]

If MS ever goes to a POSIX based UNIX type OS with a Windows GUI, just like Apple did, they would do the same thing but they wouldn't be nice enough to maintain an open source version like Apple has done with Darwin.

Isn't this exactly why the GPL licence is good? It forces people taking advantage of the Free code to keep it Free, which is better for the customers.

I really don't understand why people think that they should have the right to incorporate Free software in their product without giving anything back to the community. Afterall, you are going to benefit from other people's work so why shouldn't other people benefit from yours?

Linux will decouple and partition to scale

[Morgaine]

> Linux should absolutely never become a microkernel

Religion notwithstanding, it will become microkernel-like, because a monolithic kernel just doesn't scale. It's as simple as that.

Monolithic kernels don't scale as the number of CPUs rises, nor as the number of drivers and other logical components goes up.

Because of the need to scale, in time Linux will partition itself into independent subsystems, and slowly but surely will become a microkernel-type design, because the alternative to that would be to suffer astronomic bug rates from combinatorial complexity explosion and very poor performance from CPU contention compared to a decoupled, decentralized design.

That microkernel future is 100% inevitable, because fighting growth is like trying to sweep back the tide. In due course, the debate will just fade away, and engineering will take over. And engineers always decouple.

Re:Linux will decouple and partition to scale

[joib]

Religion notwithstanding, it will become microkernel-like, because a monolithic kernel just doesn't scale. It's as simple as that.


Nice theory. Unfortunately it seems the kernel developers that are actually working on making Linux scale to NUMA systems with O(10000) processors disagree with you: https://ols2006.108.redhat.com/2007/Reprints/lamet er-Reprint.pdf

Re:Linux will decouple and partition to scale

[Morgaine]

Examine that paper carefully and you'll realize that when you use NUMA to prevent contention from descaling your performance, then you also have to decouple the code that runs in the local memories and the management structures that control it. You can't maintain centralized controls and expect NUMA-decoupled CPUs to give you maximum speedup, since it's the centralized structures that will queue up your mountains of CPUs. The paper itself ackowledged that, in suggesting that for high numbers of CPUs you might have to implement 2-level locking schemes.

In other words, beyond smallish numbers, NUMA doesn't provide OS scalability unless you partition your management structures to match. As a result, it's inevitable that functionality will drift away from a monolithic core into autonomous subsystems, in order to make the speedup gained from NUMA as high as possible.

Contrary to your assumption then, NUMA *promotes* the breakup of Linux's monolithic structures into decoupled and decentralized designs that bear more in common with microkernels than monolithic ones. And the pressure of wanting to scale well under natural kernel growth just adds to that. It really is a tide that doesn't want to get swept back.

Re:Linux will decouple and partition to scale

[Peter La Casse]

Religion notwithstanding, it will become microkernel-like, because a monolithic kernel just doesn't scale. It's as simple as that.

By that definition, Linux is already microkernel-like, with clearly defined subsystems that interact using "message passing" (function calls). Being "monolithic" does not require spaghetti code.

Monolithic kernels don't scale as the number of CPUs rises, nor as the number of drivers and other logical components goes up.

That depends greatly on which definition of "monolithic" one uses. Arguably, a kernel can be called monolithic if it uses a single address space for its subsystems (as opposed to putting subsystems into what Linux calls "user space" and doing context switches when communicating between them), and nothing stops such a kernel from scaling well.

Arguably, a defining feature of microkernels is putting subsystems in user space, which kills performance.

Re:Linux will decouple and partition to scale

[joib]

Well yes, but that kind of decentralization into per-cpu structures etc. has nothing to do with breaking up your kernel into a bunch of user space processes and using IPC instead of function calls.

Re:Linux will decouple and partition to scale

[Anonymous Coward]

Microkernels don't mandate any particular form of communication between subsystems, just like monolithic kernels don't mandate function calls for everything.

Indeed, both IPC and function calls are just the two ends of a spectrum of communication methods, with split-transaction calls being a halfway house that both use. And Unix kernels have been using queued communications to/from drivers for 30 years, which is IPC in everything but name.

What's more, with IOMMUs just around the corner (partly to assist in virtualization), the I/O subsystems are going to be decoupled bigtime soon, and it will all be seen as natural evolution. Which of course it is ... evolution full steam ahead in the direction of microkernels. :-)

And as if the tide wasn't strong enough already, there's also the unstoppable desire for stronger security, for which separation and isolation of concerns is on page 1 of the rulebook. It will happen, just as soon as efficient ways of doing it are perfected. It will happen because partitioned and decoupled systems are the only kind of design that will meet the multitude of scaling requirements mentioned, as systems grow in size and complexity.

Re:Damnit...

[adamofgreyskull]

I think someone needs to install git! 2.6.20? psssh.

General or specific API?

[ettlz]

This seems to be an on-going trend in the kernel: FUSE, libusb, libraw1394 and ALSA all (to a certain extent) export what were traditionally kernel-bound services/drivers to user-space, while leaving the minimum necessary kernel-side mechanism, such as VFS redirection, and low-level I/O and interrupt handling. However they all do this in different ways according to the needs of the hardware. So while a generic API may be a good for unusual pieces of hardware, might it not be a good idea to develop application-specific subsystems that hook the kernel's existing ABIs (as used by current kernel-space drivers)? For example, we could have something specific for networking devices that does all the necessary set-up on the kernel side (establishing device name, wireless extensions, etc.) and communicates with a user-space driver (a bit like ALSA), which could be anything from a specific Free-Software driver to a proprietary modem driver or a wrapper for something like NDIS. Similarly with network protocols, although this might look more like FUSE.

time to switch to another OS

[dltaylor]

this has always been is an incredibly brain-damaged concept on several bases.

drivers are hard to write for a reason. they require a detailed understanding of the physical actions of the device being driven (does it interrupt, and if so, under what circumstances, and how is the interrupt from the device mapped to the CPU(s), for example, or, if it does DMA/memory mastering, what are its limitations such as alignment) and what amounts to an embedded operating environment, with necessarily very different abilities and restrictions. while there are features in the kernel to map common features with different implementations, such as managed memory, to regularize the implementations, those features have little in common with the needs of user-space applications. devices are asynchronous from the CPU in ways that user-space applications can never be. the few people who write drivers well have a different view of the system than application programmers, regardless of their competence, and even many of the best of the latter are utterly incapable of the former (and vice-versa, sometimes).

the loss of security means that Linux is headed the way of M$-Windows, which can never be secured, short of unplugging the power lead. the blurring of boundaries in the cause of "ease of use" is completely contradictory to good security practice. remember the DX9 "bug" that allowed execution of properly crafted DirectMusic streams. welcome that to the Linux world when this idiocy spreads.

thirdly, this will mean even less ability to get information from device manufacturers that would enable us to create secure and fast drivers. Linux will become a bog-slow piece of junk burdened with crapware written by programmers who have every disincentive to craft good drivers (ones that don't do things like busy-wait for ridiculously long periods). after all, once Linux is bogged down worse than M$-Windows, all the companies have to say is "it's Linux' fault; our Windows drivers work just fine, so use that".

the comment about application programmers not making the transition to driver programming is based on extensive personal observation (decades across multiple companies). very few schools teach anything like the theory, much less require the practice, of understanding how hardware works, so they simply don't know how. most hardware companies don't charge for the device drivers, so they see that as purely a cost burden, and therefore don't have any incentive to have good in-house training. when I've watched application-trained programmers try to write drivers, they don't actually think in terms of the physical time and sequence in which device events occur, and then spend ridiculous amounts of effort trying to "tune" that improperly designed code, which of course breaks with every little change in the platform.

BTW, not all driver writers make good decisions all of the time, either. some idiot decided to piss away CPU cycles shifting the SCSI STATUS byte returned for every transaction, for example.

About time

[DrXym]

Linux needs a stable ABI for drivers. Insisting that vendors release drivers for every dist, or that they open source their code is unrealistic. Open source is obviously desirable but it's still not much to end users who wouldn't have a clue how to build it.

It would be great if dists would support an ABI and produce some dist neutral packaging system that allowed drivers to be installed / uninstalled easily by mere mortals no matter what dist they had.

Re:About time

[Anonymous Coward]

Linux needs a stable ABI like I need a hole in my head. Wouldn't you agree?

Re:About time

[DrXym]

Linux needs a stable ABI like I need a hole in my head. Wouldn't you agree?

No I wouldn't. That piece and other comments from Linus are talking about the kernel developer's problems supporting an ABI. But there is nothing to stop distributions and vendors from supporting an ABI and hiding any changes in implementations. Indeed, it is absolutely in their interests to support an ABI, since it makes it far, far easier to support Linux than it has been until now.

About the only way you can get a driver at the moment is to hope that there is one in the kernel you're using already, or that the vendor (e.g. NVidia) as gone to the expense and effort of supporting the gazillion different kernels and dists out there. The barrier is simply too high for many vendors to bother. The barrier is impossible to many end users wouldn't have a clue (and shouldn't be expected to) to fetch a new kernel, or to patch and rebuild an existing one.

There would be nothing to stop dists from specifying an ABI, possibly as part of the Linux Standard Base, and supporting it in their respective dists without any hassle for kernel developers. After all, projects such as ALSA and the crypto components were independently maintained for years without the kernel folks being involved.

Re:About time

[Anonymous Coward]

> or that the vendor (e.g. NVidia) as gone to the expense and effort of supporting
> the gazillion different kernels and dists out there.

What a crock, NVidia don't support specific distros they support the mainline kernel.

I'd prefer if we could all buy Intel onboard chipsets and run their OSS drivers. Unless you're gaming or routinely running Maya with huge meshes there's no benefit to NVidia for most desktop tasks, Beryl may run smoother but show me a tangible productivity benefit. Plus the kernel component of the NVidia driver is tiny and already presents a stable ABI to their blob.

Then we get to ATI, do you really think a stable ABI would help these clowns write decent drivers? Me neither.

Everything else I own runs fine with OSS drivers, IMHO a stable ABI would only actually benefit the FCC (wireless). It would be potentially harmful to linux, the legal contortions required for NVidia's GPL avoidance scheme aren't something the community wants to encourage.

Re:Damnit...

[rolfc]

Linux esperto 2.6.22-8-generic #1 SMP Thu Jul 12 15:59:45 GMT 2007 i686 GNU/Linux Ubuntu user, One who only compile when he need it.

Total bollocks -- language wars irrelevant

[Anonymous Coward]

a systems with really really slow context switches -- compared to a kernel running typesafe code

Type safety does not ensure general operational safety. There are 1001 other sources of trouble in an OS kernel, and a good kernel keeps them all at bay.

The MMU delivers hard protection guarantees that no language can provide, so your focus on type safety just shows lack of understanding of the role of operating systems and context switching.

Re:Total bollocks -- language wars irrelevant

[Anonymous Coward]

JavaOS is typesafe and runs on machines lacking an MMU with the same reliability as machines with an MMU. Safe languages can use the MMU for virtual memory, they don't need it to 'protect' other processors from each other by creating awkward and heavy barriers. In short, you should get some school in before blowing more smoke out of your ass.

Those that don't know Plan 9

[DrSkwid]

Are doomed.

Re:Those that don't know Plan 9

[ClamIAm]

Well, I don't "know Plan 9", however I do know about Plan 9. Does this get me to purgatory, at least? :)

lol

[Weezul]

I'm pretty sure I've HURD of this userland driver idea before.

Re:lol

[Sam Douglas]

Actually, Hurd is currently based on Mach; almost all of its drivers are in the kernel. Minix 3 is a fairly good example of an operating system that puts all of its drivers in userspace.

-- Sam

In Ten Years?

[turgid]

A microkernel. What, like this? :-)

Re:In Ten Years?

[Anonymous Coward]

No, he means for a non-defunct platform.

Power Macintosh my ass.

Re:In Ten Years?

[turgid]

Funny that, it runs on many platforms. It was just that it was primarily used as a vehicle for doing Linux on PowerPC Macs in the olden days.

My point was that microkernel Linux has been available for 11 years now. There is no need to wait another 10 years.

Re:Damnit...

[mrsteveman1]

I agree with the closed driver thing, i strongly believe that many companies are never going to GPL their drivers, or even open source them at all, and user space drivers solves the majority of that problem.

Sometimes there may be a performance hit but it will be worth the stability and the (hopefully) easier installation and removal of drivers.

Userspace Drive ?

[Anonymous Coward]

Have trailing 'r's become redundant now?

Re:Userspace Drive ?

[Anonymous Coward]

"ENGAGE THE USERSPACE DRIVE!"

"Yes, Lord Dark Helmet."

There is a flash, and a sickening lurch.

When the world puts itself back together, the ship is hurtling through a tunnel of mp3s and hardcore pr0n all suffused with a faint blue light.

And The Beat Goes On

[Anonymous Coward]

Kudos to all Linux kernel developers, documenters and testers for their truly prodigious efforts!

As a token of our appreciation, let's all recite the following mantra together:

"Every day...in every way...Linux keeps getting...better and better."

Re:And The Beat Goes On

[Anonymous Coward]

> Every day...in every way...

Sounds catchy, but shouldn't that really be "Many days...in many ways..."?

It's about cloning

[seanadams.com]

Am I missing something here?

Let's take a wireless cards for example. There are many companies that know how to make wireless cards, so how does locking down the driver prevent cloning of a particular card?

It's because without knowledge of how the driver communicates with the card, the best a knock-off competitor could do is to make a functionally similar card with a driver of its own. They can NOT make a card that will work with the same drivers as the original one. (i.e. is "pin compatible").

This gives the manufacturer with existing market share a big advantage, because if a competitor comes along later and says "look, ours does the same thing!" then the OEM or embedded systems engineer (people who buy thousands of these things) will say "yes the specs are similar but it doesn't work with our supported drivers. It's not worth it to us to qualify a new driver even if we can save a few cents per unit."

However, there is a secondary concern that knowledge of the driver interface actually helps a lot for someone to learn how to implement a competing technology even if it doesn't use the same driver. It's not like the data sheets just say "the magic numbers are 0x5724 and 0x3217 etc." You actually need to reveal quite a lot about how the device works in order for someone to be able to write a driver for it.

The demand for linux drivers needs to reach the point at which a given manufacturer perceives that whatever IP they might expose by releasing Linux drivers is less of an impact than losing out on those sales. We are almost certainly at that point already, but most manufacturers don't realize it.

Re:It's about cloning

[Dan Ost]

The demand for linux drivers needs to reach the point at which a given manufacturer perceives that whatever IP they might expose by releasing Linux drivers is less of an impact than losing out on those sales. We are almost certainly at that point already, but most manufacturers don't realize it.

I was under the impression that Linux had less than 2% of the desktop market. Is that really enough computers to sway the decision making of hardware manufacturers?

Re:It's about cloning

[jZnat]

And I was under the impression it was at 7%. See? I can make up statistics too. Nobody knows the per centage, and nobody will ever be able to know due to the nature of it. I can guess that there are at least as many Linux or Unix-like desktops out there as there are Mac OS X desktops, especially when you include workstations and dumb terminals (which non-techie people will all refer to as desktops anyhow). That's a pretty big number of people to ignore, and these hardware companies don't seem to notice that.

There are other companies like Intel which are recognising this fact and working with Linux, Xorg, etc., to get full, free drivers working for their hardware (they even employ some people to write these things). As it stands, the main companies that don't get it, full stop, are Broadcom (I couldn't care less about their shitty hardware, however), AMD/ATI (they can't write graphics drivers worth shit anyhow; just ask any gamer), and a few others. NVidia at least almost gets it and writes very functional drivers for Linux (Xorg and Xfree86 actually, although I don't know if they're compatible with XF86 anymore now that nobody uses it), but they aren't on feature-parity with their Windows counterparts. Plenty of Asian companies (Taiwan, Japan, etc.) get it as well and provide full documentation for their hardware in order to be included in Linux, BSD, et al.

So, as it stands, companies will either have to adapt (provide adequate documentation or open drivers or hope that someone successfully reverse engineers their hardware) or die, just like some other commonly-hated companies around here like Sony BMG, Universal, Warner Bros., Hollywood, etc.

Re:It's about cloning

[Dan Ost]

And I was under the impression it was at 7%. See? I can make up statistics too.

I apologize for not giving references. Since we're talking desktops, and since most desktops are used for browsing (among other things), here are a couple sources that will help give some ballpark estimations of Linux penetration on the desktop.

W3 schools, a developer site shows 3.4% of their traffic comes from Linux machines. Since this is a site aimed at developers, this is probably higher than the actual desktop percentage. See http://www.w3schools.com/browsers/browsers_os.asp if you're interested.

http://marketshare.hitslink.com/report.aspx?qprid= 5 doesn't have a column for Linux, but the "other os" column shows 3.54%. It aggregates stats from thousands of websites, so is probably more representative of the typical desktop than W3 schools and can probably be safely used as an upper limit.

I'd love to see stats from other sources if anyone cares to post links to them.

Kernel Problem?

[Thyrteen]

Wow, the kernel's been mainlining drivers without my knowledge? This is serious...

Re:Damnit...

[thethibs]

Userspace drivers are not really a new groundbreaking idea now are they

I can make a case for deja-vu 1968: SDS Sigma 7 BPM.

What about security?

[mwfolsom]

Surely this has security implications - know that you can always become root but with this someone could craft a driver that does evil things and spread it around.

M-

Re:What about security?

[petermgreen]

root already has the power to load custom code into the kernel which in turn can do whatever it likes to hardware.

you can do DMA

[r00t]

The kernel won't help you do DMA nicely, but it can't stop you. Anything with control over a PCI device can set off a DMA operation, which the PCI device will then perform. PCI DMA is done from the device, not the motherboard.

This is a massive security hole. One of these drivers can use DMA to read your kernel memory. It can then send this over the network. It can look for data structures in the kernel, then DMA some code and function pointers into the kernel. It's trivial to take control of the system.

Re:you can do DMA

[njchick]

Would not IOMMU close this hole?

Re:Damnit...

[JackieBrown]

2.6.22-8? Ubuntu is cutting edge considering the latest is 2.6.22-1

http://www.kernel.org/pub/linux/kernel/v2.6/

What?

[Anonymous Coward]

So what about wireless drivers? What about winmodems? What about gigabit ethernet cards? What about RAID? What about scanners? What about printers? What about digital cameras and music players? What about sound cards? What about syncing with your PDA? What about every single piece of hardware out there besides video cards?

Re:What?

[ZorbaTHut]

Some of those are simple data transfer interfaces. Most of those have drivers available at this point, either through reverse-engineering efforts or through actual drivers. Some of those are more complicated (it wouldn't surprise me if much of the printer logic is in software at this point, for example).

The same basic economic forces are pushing a lot of them. Software has to be written once and can be copied forever. CPU cycles, RAM, and bytes are cheap. Why not push more into software, and write all your hardware control as "driver" code?

You can divide drivers into three basic categories - drivers that are provided closed-source at best, drivers that are provided open-source by the manufacturer, and drivers that the manufacturer doesn't need to bother providing open-source because they're so fucking simple. A significant amount of the above falls into the latter category. And some doesn't. Shrug.

Re:What?

[marcansoft]

it wouldn't surprise me if much of the printer logic is in software at this point, for example

Say hi to the HP DeskJets that use PPA (the cheap ones). Their logic is basically composed of an MC68K CPU with enough RAM to hold one print sweep and control the motors. The protocol literally includes commands for advancing the paper a certain amount and sweeping the cartridge (with raw print dot data).

Re:Damnit...

[rolfc]

Yes, and no. Ubuntu gutsy is in alfa.;)

But does it run ZFS?

[Anonymous Coward]

No? Too bad. Let me know when Linux is ready to be relevant again.

Re:But does it run ZFS?

[PitaBred]

Show me a Fortune 500 (or even 1000, let's get crazy) company that uses ZFS in a critical space. ZFS isn't relevant (yet) compared to Linux.

Re:But does it run ZFS?

[Thundersnatch]

Show me a Fortune 500 (or even 1000, let's get crazy) company that uses ZFS in a critical space. ZFS isn't relevant (yet) compared to Linux

Umm... I dunno. Maybe Sun Microsystems, which sits at #187?

ZFS was released way back in late 2005. Solaris is still pretty popular in the Fortune 500. I would imagine at least a few of those customers are using ZFS, even if they're only to try to stretch a storage budget that just isn't big enough for EMC this quarter.

sprouts

[McGiraf]

"Yes, and no. Ubuntu gutsy is in alfa.;)"

it's alfalfa not alfa.

Designing an OS

[Anonymous Coward]

It looks like Linus has finally realized that Tannenbaum was right.

Re:Damnit...

[RMingin]

Ubuntu = 2.6.22.0 Ubuntu rev 8
Kernel.org = 2.6.22.1
Different, but thanks for playing the Smartass Game! You lose, play again soon!

That's no excuse

[Anonymous Coward]

Keep in mind how much of a modern graphics card's abilities are now located in software.

Yep, especially built-in graphics chips like the Intel GMA950 line ... which has completely free drivers.

More than once, a driver update has come out that has *massively* boosted graphics card speed.

Sure, because they used a generic software renderer, and then added driver code to do it on the GPU. When you add SIMD support to your compiler, other things get faster, too. This really doesn't have anything to do with whether it can be open-source or not.

To make it even worse, I'm told that many wifi cards are only legal because they're not open-source. Sound bizarre? When they're sold, they're sold with certain restrictions on frequency and power. These restrictions are located entirely within the drivers.

This is, of course, complete bullshit. There are plenty of illegal things you can do with the source code. I could add a kernel function to DDOS the Pentagon to my NIC driver. That doesn't mean my gigabit ethernet driver can't be open-source. It just means if you modify it to do something illegal, well, then it's illegal.

We're well past the point where hardware interfaces can be described in half a dozen pages. We're well past the point where "hardware devices" even exist entirely in hardware.

We've already got people working on a fully open-source graphics card. If knowing how to build a complete graphics card, plus knowing how to write accelerated 3d drivers for existing graphics cards, plus knowing how to write software fallbacks for this, isn't enough, then what's left?

The excuse "they're violating all kinds of patents in their drivers" is actually plausible. The reasons you listed aren't.

Re:Damnit...

[JackieBrown]

Always happy to play.

Once again...

[bogd]

...I see a first post modded "Redundant". Is there some kind of tradition around here that I'm not aware of?

Re:Once again...

[Garridan]

Yes. The moderator guidelines suggest that you read newest posts first.

Stable Userspace

[Anonymous Coward]

Linux Kernel Still Has Unstable Users

Processor schematics

[flyingfsck]

Schematics are nice, but there is a small problem though - I doubt that your house is big enough for the schematics of the north bridge, never mind the processor...

Re:Processor schematics

[ultranova]

Schematics are nice, but there is a small problem though - I doubt that your house is big enough for the schematics of the north bridge, never mind the processor...

Assume a processor contains 50 million transistors. Number them each with a 32-bit integer, which takes 4 bytes to store. Then number the inputs and outputs of each transistor with another 32-bit integer (better safe than sorry :). Then you can give the transistor-transistor connections as pairs of four integers (the source transistor, the source pin, the destination transistor, the destination pin), taking a total of 16 bytes to store. If every transistor connects to every other transistor, this means 5*10^14 connections, which take a total of 8*10^15 bytes, or 8 petabytes; if we assume a more reasonable 4 connections per transistor, we get 200 million connections, which take a 3 200 000 000 bytes - 3.2 gigabytes to store (but of course this contains many duplicates). I think it would fit in my hard drive just fine...

Re:Processor schematics

[|<amikaze]

That schematic, as described, is pretty much useless. 50 million transistors with no annotation to mark which ones belong to which part? (Is this cache? Is it part of the ALU).

For an open source analogy, that's pretty much the same as getting a handful of .o files.

Re:Processor schematics

[ultranova]

That schematic, as described, is pretty much useless. 50 million transistors with no annotation to mark which ones belong to which part? (Is this cache? Is it part of the ALU).

Of course it's pretty useless; it doesn't tell the transistor type either, for example. However, it is useful in estimating, in rough terms, the required storage space for the schematic.

Consider this.

[jd]

Infiniband has an end-to-end latency of 8us and can scale to 160 Gb/s. Dolphinics SCI has an end-to-end latency of 2.8us. Picture a SAN that beats the crap out of most local storage. Now picture driving this monster through a 21us latency context switch and a data copy between kernel to userspace. It's not a pretty thought.

But what happens if you do this right? Sure, most single drives can't handle that kind of throughput right now, but scalability and future-proofing are important. There's no point in having a mechanism which is OK for today but useless three weeks from now.

Re:Consider this.

[Verte]

The data copy can probably be taken care of through memory remapping or DMA*, but you're right, that context switch time is still completely silly. One wonders how Intel could have stuck with such brain-dead behavior for so long, and why they aren't going to do anything about it. Furthermore, I don't see how zeroing a cache can take so long! That's nearly as slow as moving zero into each slot by hand!

*Something mk designers frequently overlook. I don't think there's anything particularly bad about address spaces that overlap. I think this is the middle ground between microkernels and monolithic kernels that is The Right Thing- address space separation except where it's obvious that it's a good thing. Sometimes it's good to pass pointers to entire data structures around, and not particularly difficult on x86.

Re:Consider this.

[jd]

Trust me. If someone were to produce a clone of the latest Core2Duo with only one enhancement - zeroing a cache in half the time - and just enough cash to actually get a few chips circulating, Intel WILL reduce the time for that process by a few microseconds more by the end of the week. Same as they did with Transmeta and the power saving.

Nobody even needs to actually mass-produce the buggers - Transmeta's first batch didn't even work right and had to be recalled - they just need to scare Intel into thinking they could. So long as Intel believes they are the best, they will do nothing. The second they think they're not (even if it's just a skillful illusion) is the second they'll modernize the flawed part of their design.

Oh, eventually they'll catch on, as these mysterious competitors never actually appear, but if it's good for even a few upgrades on the antique elements of the design, then it'd be worth it.

Sorry, MS doesn't need it...

[Anonymous Coward]

Since the Windows GDI (Graphical Device Interface) has been doing the EXACT same thing which Lunix is making a "new and magical feature" of Lunix, Windows doesn't need it. They've been doing the same thing since at LEAST Windows 95.

Once again, Slashdot fails to understand the multitude of ways in which Lunis is constantly chasing Windows 95's tail lights. Lunis isn't doing anything new or revolutionary, and never has been. And that, dear FOSSies, is why Lunix remains a third-tier OS, and will never be anything more.

STILL copying Windows 95?

[Anonymous Coward]

Wow, Linus's great idea sounds exactly like the Windows GDI ( Graphics Device Interface).

Is there ANY aspect of Windows FOSSies aren't willing to steal and call "new"? It seems not.

Re:STILL copying Windows 95?

[Anonymous Coward]

The TCP/IP stack?

Re:Tail Light Chasing!

[Ripsnorter]

No you don't get how things work around here, when Microsoft does something it is bad. When Linus does something similar it is good.

Re:Tail Light Chasing!

[j-pimp]

It appears Lunix intends to catch up to Windows 95's tail lights by trying, piece by piece, to turn Lunix INTO Windows 95. Hardly surprising: if the Lunix community had any talent or imagination, they wouldn't still be chasing an operating system which is approaching 13 years old.

Well he already caught up to and surpassed a 37 year old operating system. Actually, user mode drivers seem to be new to VISTA, although I think there is something similar in earlier NT kernels.

Its called cross pollination btw. I'd like Linus to go stealing all the good ideas from the non unix OSes.

In theory, yes.

[r00t]

In practice, where are you going to get a fully capable IOMMU?

The one on AMD64 chips, intended to be just an AGP-GART, does not protect the full address space.

Intel has documented the functionality of an IOMMU for the Linux kernel developers, but makes no mention of actual or even proposed chipsets with the feature.

To protect devices from being used to attack other devices, they can't share busses as is normal for standard PCI. You need one IOMMU per bus.

Andy Tanenbaum bitten by Raccoon

[L505]

In other news, MINUX developers have recently announced that MINUX has been rewritten to now focus on having all the device drivers in Kernel Land. Andy Tanenbaum made the decision to make MINUX become LINUX when he was bitten by a raccoon in his garbage can that he was sleeping in outside.

Re:Andy Tanenbaum bitten by Raccoon

[Anonymous Coward]

It's not surprising: swift, radical feature changes are a hallmark of Rabid Application Development.

Re:Andy Tanenbaum bitten by Raccoon

[L505]

This is the close up shot of the raccoon that represents Minux.

Note: I like some of the ideas behind Minux, I'm not making fun of Minux software, I'm just disappointed in Andy's choice for a cuddly animal that represents Minux.. I don't think Raccoon's are all that cuddly, nor are they great looking, nor are they interesting, nor are they special in any way. Plus, it reminds me of someone who eats trash and lives in garbage cans. Why would this be a good choice for a mascot?

Report from the front line

[raverman]

I use the UIO framework for half an year now - starting with patches, and lately from the main release. I had not used Linux a year ago, let alone program for it. In the moment I have completed two drivers, and await green light for the third. Yes, they are embedded drivers, and yes, they are simple. But they work and get the job done, allowing my company to migrate to Linux and sell cheap and working custom devices. I for one welcome our Usersapce masters...

Re:Damnit...

[daskinil]

Is this similar to the way video drivers in vista have been moved into user space? At least according to microsoft- this will actually speed up the drivers if implemented right, as opposed to slowing it down. Something about the cpu switching from protected mode to user mode or something. I do not know the details. If someone does- please contribute.

Re:Damnit...

[JackieBrown]

Always happy to play