When we talk about device driver interface, there should be three styles, not two:
1. Source code level interface.
2. Binary code level interface.
3. interface for user process device driver interface.
According to what I believe, 1 is usually good idea. Having 1 with full GPL, will prevent non-open device driver availability, and help device driver programmer for they do not have to re-write driver whenever internal interface changes.
2, on other hand, is somewhat little bit more disgusting. You can make it from 1, if you designed the interface. But usually not necessary.
3, lastly, I belive, is something we SHOULD have. This interface will give driver programmer to do debugging at user space, can test long run test to see for memory leak, etc.
Since user process device drivers performance are usually terrible due to lots of system calls required, if proprietary device drivers are being released in binary-only user process style, there shall be only three cases:
1) user choose different HW, for it performs terrible in Linux
2) HW vender will give up, and make program open
3) they decide Linux not to be their market
Any case seems OK to me.... I mean, it's really TRAP for those who do not make device driver source code open. Once they choose 3 for solution, Marketing and Sales persons will start helping community, by forcing development section to SPEED UP the device driver.
If source code could not be open due to BUSINESS reason, we should give them the reason why it is better. Not by giving ideal, broad view. By showing concrete vantage.
2005年11月9日
What was the problem behind?
Greg,
I do wish to know about "what was the reason behind their problem."
# because it lacks subject, it might be of NFH's reason, but might be of open source side.
# what were you trying to say?
I do have one point of sympathy about NFH's opinion having "Abstraction Layer."
When people outside the HW vendor tries to write device driver, they ether reverse engineer, or read manual. Anyway, HW is already fixed, and solid. Solid enough so that reverse engineering do works. Solid enough so that people can write manual about it.
This is not so for programmer INSIDE the HW vender. HW is not solid, the interface ( and the timing of interfaces ) changes very rapidly. I even experenced interface changing 3times within a week. I see many peoples not believing this, but it does.
How can they change so rapidly? Didn't creating new mask for chips takes about several million dollors? Easy. Because the changes are being caused by micro code, the software.
Hard Coded chips are already there, with plenty of bugs (most of them are still not being found yet ). HW venders do not have extra budget to re-design a chip again. How do we fix HW bugs? with micro code, and if we can't? we call it spec, and device driver have to handle it. Because micro code is under development, they change. The change speed of under development microcode is even faster than kernel interface, and bug list grows like ... like ... I think it's the fastest growing stuffs in the universe...
But on the other hand, many vender wish to have their driver on newest kernel as well. As result, device driver programmer have to take care of two changes at once. One from micro code, and other from kernel internal interface change. This will kill device driver programmer.
How can we help device driver programmers from dying? Fix the interface of kernel to solid state, so that programmers can concentrate on interface change of HW. At least, you can't blame people who came up with this idea, no matter how stupid it may be.
I don't know if this idea is good or bad. But I do have sympathy with people working inside HW vender, trying to struggle for device driver, and those who trys to ease their works by defining Abstraction Layer.
Also, I do know that in old days, well designed Abstraction Layer did last for 10 years without change, and did scale. I don't know if we can say same thing for next 10 years, or even 5 years. But it did in past. How can you blame if people next to hell dreamed of new design lasting for next decade...
If Abstraction Layer is bad, we should not simply give them a reason why it's bad, but also how to solve their problem. How to ease their device driver programmer, without telling them to look for a change within kernel every week, nor month.
Not writing a driver till HW is solid, is not the answer. That's for sure.
I do wish to know about "what was the reason behind their problem."
# because it lacks subject, it might be of NFH's reason, but might be of open source side.
# what were you trying to say?
I do have one point of sympathy about NFH's opinion having "Abstraction Layer."
When people outside the HW vendor tries to write device driver, they ether reverse engineer, or read manual. Anyway, HW is already fixed, and solid. Solid enough so that reverse engineering do works. Solid enough so that people can write manual about it.
This is not so for programmer INSIDE the HW vender. HW is not solid, the interface ( and the timing of interfaces ) changes very rapidly. I even experenced interface changing 3times within a week. I see many peoples not believing this, but it does.
How can they change so rapidly? Didn't creating new mask for chips takes about several million dollors? Easy. Because the changes are being caused by micro code, the software.
Hard Coded chips are already there, with plenty of bugs (most of them are still not being found yet ). HW venders do not have extra budget to re-design a chip again. How do we fix HW bugs? with micro code, and if we can't? we call it spec, and device driver have to handle it. Because micro code is under development, they change. The change speed of under development microcode is even faster than kernel interface, and bug list grows like ... like ... I think it's the fastest growing stuffs in the universe...
But on the other hand, many vender wish to have their driver on newest kernel as well. As result, device driver programmer have to take care of two changes at once. One from micro code, and other from kernel internal interface change. This will kill device driver programmer.
How can we help device driver programmers from dying? Fix the interface of kernel to solid state, so that programmers can concentrate on interface change of HW. At least, you can't blame people who came up with this idea, no matter how stupid it may be.
I don't know if this idea is good or bad. But I do have sympathy with people working inside HW vender, trying to struggle for device driver, and those who trys to ease their works by defining Abstraction Layer.
Also, I do know that in old days, well designed Abstraction Layer did last for 10 years without change, and did scale. I don't know if we can say same thing for next 10 years, or even 5 years. But it did in past. How can you blame if people next to hell dreamed of new design lasting for next decade...
If Abstraction Layer is bad, we should not simply give them a reason why it's bad, but also how to solve their problem. How to ease their device driver programmer, without telling them to look for a change within kernel every week, nor month.
Not writing a driver till HW is solid, is not the answer. That's for sure.
2005年11月6日
The most powerful subwoofer on the planet
これはすごい。これ、何だと思いますか?
扇風機じゃありません。換気扇でもありません。
重低音用サブウーハーですよ。
Eminent Tech TRW 17 というこいつは、WebPageによると、ファンが左右に回転して「送吸風」を発生させ、それによって 1Hz の波を作り出すのだそうだ。
ま、確かに。旧来のコーン紙を動かす方式では1Hzのスピーカーを作るのは至難の業だわな。
普通のコーン型のスピーカーだと100Hz出すのに片道最大3cmぐらい移動できるように出来ている。同じ速度でコーン紙を動かすと、1Hzだと片道300cm…3mだ。3m! もはやそれはスピーカーとかではなく「棒」である。
いや、まぁ、それにしたってさ。原理はわかるけど、誰? これを「造ろう」って言った人は。