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.

0 件のコメント:

コメントを投稿