On Sun Oct 02, 2005 at 22:50:17 +1000, [EMAIL PROTECTED] wrote: >On Fri, Sep 30, 2005 at 09:26:45AM +1000, Benno wrote: >> I know, but I don't agree with him. If the language is good, there is no >> reason why it *shouldn't* be used for device driver programming. >> >> Device drivers are, in general, buggy pieces of crap, so having a higher >> level language to program them in would be a *really* good thing. > >Remember that when you are coding to hardware, half the "program" is >invisible and out of your control (out of the compiler's control too). >Half the program that you are building is the hardware itself, >it is an active component, not a chunk of memory. The hardware does >things and you have to also do things in the right sequence, at the >right time. Often the device driver code is perfectly correct, it just >doesn't perfectly match your particular bit of hardware. Either one >manufacturer has copied another manufacturer and got it wrong or >the driver was written for an older version of the card and the new >cards changed behaviour (but the manufacturer never told anyone) or >the driver was written to reverse engineered specifications and no >one really knows what the hardware is doing anyhow.
Sure, but those things shouldn't cause the driver to crash. They might cause it to fail, but that is a completely different story. And of course the device itself might do some bad write to memory. (If we had I/O TLBs of course this would be less of an issue.) In any case, even taking in to account all those problems, device drivers are still, in general, buggy pieces of crap. This is why there is attention within m$ on the SLAM project, and project like Nooks on linux, to mitigate the problems with device drivers. >> I've written bindings to allow you to program drivers in python >> before, unfortunately the result wastoo slow :(. > >Timing is actually part of your program when you write device drivers. Less so than you might imagine on things like IDE. >> So a higher level >> compiled language like O'Caml might be kind of cool. > >In theory, it sounds good. You hit a big snag when you look at what >makes "functional" languages work, which is that each whole unit >of code has well defined inputs and outputs and the behaviour of >that code-unit does not depend on influences outside the scope of >those well defined inputs and outputs. It's a nice mathematical >approach, but once you put a piece of hardware into the mix, half >the program becomes invisible and out of your control (i.e. the >hardware half). The "functional" paradigm starts to break down because >any bit of code that touches a hardware register is now capable of >behaviour that the compiler doesn't understand. > >Functional languages are good for transforming a well defined input >into a well defined output. They don't handle "real world" messiness >very well. Most functional languages have a way to escape this in a well defined manner. In any case, I'm not advocating everyone should be start writing drivers in C. In fact I'm going to keep writing drivers in C because it is still current state of the art. What I am saying is there are plenty of problems that you encounter when using C, and trying to use a higher level language, such as O'Caml, to see where some of the complexity can be taken care of by the language is an interesting research topic. In the end it might be totally useless for it, but I don't think you can know that until trying it, and more importantly finding out the specific reasons why it is good/bad is the interesting part. Benno -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
