"I don't care what anybody else says - x86 is *so* totally dominant, that other architectures have to live with the fact that 99.9% of all drivers are written for and tested on x86. As a result, anything else is 'theory'. Are some drivers good and are careful? Yes. Are most? No, and even if they were, people making changes would mostly test them on x86. Architectures should strive to basically act as closely as possible to x86 semantics in order to not get nasty surprises."
| Easter Eggs in windows XP | 39 minutes ago | Windows |
| Kernel Module Oops! TRICKY PROBLEM! | 1 hour ago | Linux kernel |
| usb mic not detected | 16 hours ago | Applications and Utilities |
| linux-2.6.10 | 22 hours ago | Linux kernel |
| How to detect usb device insertioin and removal event ? | 1 day ago | Linux general |
| Extended configuration Read/Write | 1 day ago | Windows |
| Add ext2 inode field | 1 day ago | Linux kernel |
| the kernel how to power off the machine | 1 day ago | Linux kernel |
| struct gendisk via request_queue | 2 days ago | Linux kernel |
| page initialization during kernel initialization | 3 days ago | Linux kernel |
Yet again Torvlalds f*cks up
Great, so the maintainers of every non-x86 port have to pander to the, often drainbamaged, ways of doing things in the x86 world. And what happens when x86 finally dies (or evolves to the point where compatibility with a piss poor ISA from the late 1970's is no longer a necessity)? What about all those embedded systems, primarily based on ARM and PowerPC, where inefficiencies thanks to having to "act like an x86" really hurt?
It's time someone like RedHat took the plunge and formally forked the Linux kernel. Having Linus "x86 only and screw testing" Torvalds as head honcho is causing big problems for the distro maintainers, who have to have huge test suites and masses of patches (see the source RPM for your typical RedHat kernel) in order to have a shippable kernel. Linux has already suffered enough because a decent kernel debugger had to be maintained outside the official, Linus blessed kernel, and there was no version control system for so long. It still suffers because there's no centralised build system - and given the current chaotic setup it would take someone like a RedHat to provide that.
Are you...
Are you seriously suggesting that Redhat should fork the kernel because Ed in Michigan wrote a webcam driver, and when you plug the webcam into the SPARC box you got off eBay it doesn't work. Good luck with that.
1. x86 is the dominant platform to write drivers against. Mostly because it's commodity grade and highly pluggable to start with.
2. Other architectures, like arm for embedded, tend to have 'fixed hardware'... Which is to say you write the driver(s) for the device, or fix the x86 driver for the deice, build a kernel, and pretty much forget about it for the life of the device. There's pretty much no expectation of plugability.
3. The core of the kernel tends to build well on other platforms... and that's really all you want... See #2.
Expecting driver to be perfect for every architectures would pretty much mean 'no drivers'. Having an x86 driver, even if it embeds x86 assumptions, at least gives people on other architectures a place to start if they need a driver.
Re: Are you...
What Torvalds is advocating is that maintainers of non-x86 ports intentionally kludge things to "act like x86", and Ed's imaginary webcam driver is simply a straw man. I acknowledge that a driver may be written for x86, and only tested on x86 because that's the sole architecture available to the original developer, but it's a bit much for Torvalds to state that this is a good thing because one architecture dominates his world view. Other Unix like OS'es, particularly OpenBSD and NetBSD, benefit greatly from drivers and kernel API's that try to be as architecture neutral as possible.
irony
you know, this is heavily ironic to me, as ten years ago, i got chewed out by a goodly part of the linux kernel team, for treating everything like an X86. as a response, i purchased a sparc off of ebay, and learned to not DO that.
personally, I concider this a symptom of a social disease thats overtaking linux in general: corporatism. its no longer about interesting hardware, or technologies, its about keeping linux 'enterprise grade'. if ED in michigan's webcam driver is being integrated into the kernel, the kernel development team has the option at that point to send ed to a document about how to make sure not to cause stupid portability issues. they certainly used to.
instead, we get "the world (AKA our enterprise xen servers) is an x86, shut your trap".
not that i think theres anything to do about it. just be aware, we USED to stand for more. only by holding ourselves to a higher standard individually, can we recover from this.
I'm the first RE. I'm by no
I'm the first RE.
I'm by no means an 'Enterprise (Only) Linux' advocate. I think that it's of fundamental importance that the core of the kernel remain portable. That it should build and work on x86, ARM, Sparc, and PPC at a minimum. I also support the idea that drivers should be reviewed for the most obvious x86isms...
However, expecting drivers to 'just work' 100% of the time on non-x86 just isn't realistic. If you put that bar there nobody would get Ed's webcam driver, which is bad for everybody.
If there is use for a piece of hardware on a non-x86 platform beating the x86isms out of it is easier than having no driver at all. The funny bit is that 'Ed's driver' probably had no counterpart on the Solaris platform in the fist place.
Now if you look at oh say, ARM for embedded--- Where the money's at. That's all dedicated hardware. Which is to say on kernel build where you get drivers working for dedicated hardware once. Once again, beating the x86isms out just once, for one kernel version, even if the patch doesn't hit mainline, is all you need... And is a far better starting place than having a technical manual and 'no code'.
There's always FreeBSD and
There's always FreeBSD and OpenBSD for those who know better...
CloseNoCigar
FreeBSD anyday over LOSNIX, OpenBSD anyday over FreeBSD. LOSNIX, anyday over Mico$oft.
Are you already 14 years old
Are you already 14 years old or younger?
ahh
>Great, so the maintainers of every non-x86 port have to pander to the, often
>drainbamaged, ways of doing things in the x86 world. And what happens when x86
>finally dies (or evolves to the point where compatibility with a piss poor ISA
>from the late 1970's is no longer a necessity)? What about all those embedded
>systems, primarily based on ARM and PowerPC, where inefficiencies thanks to
>having to "act like an x86" really hurt?
And what inefficiencies would you be talking about? Can you elaborate? And can you also provide any examples and numbers? That would be great.
How about memory ordering?
One place that the core kernel very much does not hold to "all the world's x86" is the issue of memory ordering in a multiprocessor environment. The x86 model is very simple to program, but keeps the bar low on performance. The core of the Linux kernel actually aspires to the DEC Alpha memory ordering semantics, which are among the most aggressive performance-wise.
Note that I very carefully said "the core." Drivers might slide by that rely on, for example, the CPU never reordering stores to a non-cacheable memory space. Some CPUs require explicit memory barriers, whereas others do not. IIRC, x86 requires a "fence" and a load to ensure a series of writes has landed, but does not require explicit barriers between stores to keep them in order if they're all going to the same end point. Other CPUs deviate from this at their own peril, since this is the kind of assumption that easily creeps into a driver and doesn't necessarily jump out at you on review.
I'm sure there are other examples. That's just one that sprang to mind.
--
Program Intellivision and play Space Patrol!
That's one of the things
That's one of the things this lkml thread is about. Note that Linus never said anything about restricting memory ordering in general, but just that device drivers should be given x86-like semantics for IO space access by default. Considering how many drivers there are and how many are developed and tested primarily on x86, this is a fine idea.
Those that know what they're doing could use relaxed methods.
Can you explain more?
The core of the Linux kernel actually aspires to the DEC Alpha memory ordering semantics, which are among the most aggressive performance-wise.
I'd be very interested if you could elaborate on this. I don't know a great deal about the Alpha memory model and ordering semantics; I learned assembler on the x86, like most people these days.
"And then there's Alpha..."
Here's where I'd start: http://lxr.linux.no/linux/Documentation/memory-barriers.txt
There are several references to Alpha in the body of the text, including this gem at the end:
They also point to:
--
Program Intellivision and play Space Patrol!
"I learned assembler on the
"I learned assembler on the x86, like most people these days."
No wonder most people get scared off then.
x86 is nothing
I started with TMS9900 assembly language. Now that is a special assembly language. It's like PDP-11 assembly on drugs—for example, your registers are stored in RAM, and you are expected to change their address on the fly. To complete my brain warpage, I learned 6502 next, where I gave that poor accumulator and zero page quite a workout. Only after that did I finally learn x86.
x86 is wacky, but it's far from the wackiest CPU out there.
--
Program Intellivision and play Space Patrol!
Here's an idea - why don't
Here's an idea - why don't YOU fork it?
You so totally sound like you know what you're talking about.
Totally
Yeah, totally dude. Eloquent as always.
Oh, and I *so* totally don't care what Linus says.
YMMV.
The guy isn't paid to be
The guy isn't paid to be eloquent. He's at the top because he can code, and he can lead.
You left a tag open
Wait, you forgot a tag open. Let me close it for you:
</sarcasm></jealousy>
Fixed that for you.
</ineptitude>
I didn't say he isn't at the top. I didn't even say he can't code or lead.
I said he is at the top not for that reason.
He's at the top because it's
He's at the top because it's his kernel.
Out of interest, what does Linus get paid to do ?
Me too
Yeah! I _also_ totally don't care what you say. Linux will rule anyway...
Linux is the new Windows.
Linux is the new Windows.
Except it's completely Free,
Except it's completely Free, so it can be whatever you want it to be - hooray!
Sweet delusions...
It's not completely free because of binary blobs, and it hardly can be whatever you want it to be because it's barely documented.
I think you misunderstand
I think you misunderstand Linus. What he's saying is simple.
* Almost all the market is x86, so it gets the most eyeballs and testing.
* non-x86 gets almost no testing or eyeballs because few people are interested in it
* if people actually cared about a particular non-x86 platform (say the ARM) and did the necessary testing and eyeballing, he'd be happy to accept patches and ensure that those users were not alienated.
* The non-x86 people don't seem that interested (especially since they're more interested in keeping a separate branch...e.g. the 64 bit x86 until recently), so he doesn't think that all kernel development should be held up for months while the non-x86 people eventually find enough people to do proper testing....that's the tyranny of the minority.
* Therefore, x86 work gets priority.
His logic is totally reasonable. I chose Linux over Windows knowing full well that there were some things that I won't be able to do. It's a trade-off. Anyone choosing a non-x86 platform is making a similar trade-off.
If you want to fix it then you have two solutions:
1) Make sure that your pet non-x86 gets enough eyeballs and testing for all device drivers. Put your money where your mouth is.
2) Every release or two, provide a separate "stabilization branch" which slowly includes fixes for device drivers for non-x86 platforms. Merge those changes back to the mainline kernel whenever possible.
x86: It like monopoly
Only Redhat seems to be the solution for Liunx woes.It pain to work around with linux on platforms other than x86
Linus Is So Totally Stupid
I don't care what anybody else says - Linus is *so* totally stupid, that other developers have to live with his idiosyncrasies.
Sheesh, guys
Go ahead and shoot the messenger if it makes you feel better. Linus is simply being real here, even though reality isn't what we might all wish it to be. He could instead choose to live in a fantasy world in which CPU selection is driven by design merits, but he's too pragmatic for that. If you want to live in that world, you're invited to do so, or--- better yet--- you can strive to make it become the new reality. But so long as the market is saturated with x86, folks like Linus will continue to make x86 support a priority.
Why don't you use Windows then?
I've chosen to live in a world in which OS selection is driven by design merits. I can't see why should it be any different regarding CPU selection.
I am using Windows
I fully expect to get my head bitten off for admitting that.
To make Windows livable, I have loaded it down with MinGW and The GIMP and Firefox and all that jazz. Heh, I usually manage files with bash in an rxvt.
I use Linux (various distributions) for every other computer in the house besides my laptop. Mostly the other computers have networking tasks for which Windows is very ill-suited. But for the job of running Windows applications and using hardware for which there is insufficient documentation to make good free drivers, Windows is indispensable. I hate that, but I cope.
a little something for people who hate x86
http://www.terrasoftsolutions.com/products/powerstation/intro.shtml