-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.
> 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.
> 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.
- Tel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iQIVAwUBQz/XiMfOVl0KFTApAQLlcw//cpsVINdmQBZTrxXTcdKP9XVoA7JjOiqA
EsPnY+yuzztIZzC2lzNJrNW4jiRaNQZDM8TwhaEwDnIZgGgqR2uTp94H4OVDEMbH
bTG2FUhZ+m86ytcS7qTSeVhVVhNj+JKyBT9NaDtGGJf6aYz9BqSHOtdRrMBC0XZO
rxdraJg7l/otyrArxWaLZeLW2k6Dchi5XfNE6RG/R3kesKIlupk7Zts8UsAygRrq
P5e7ZPI7WuGQBghxBWGAU5kqRX/8FadtrMEfPb4b7Ait4W4bWYRlSVKdKKTuhY5j
42FaCmwWNj8gzCDW8e5kjBRClu7gGFUSSNHWqtXSSN9PsvCtmmoxsXmelwYc63og
QVnPeFDP8iBUhzsCOr0k9pvLkD4Pf9uDxKEs8LLTciwy7PRmr8m6ilbWYPPk9H+R
uSrYT9xo50IUnEoFCP7JgzbYoUYF8FkrcgsIdV8zPsyp5q1nevjK12CtsFu0RBu/
2GooS8MRSR092YAqPRvP7dgvIzk6Jo9lCGP9zbtPyjEd5BMhN1ZnTFJsnprG2+9L
qrSwrwfW7jc1IXjSq4BIDtiPRJDjMyDq3A6cbubG6X/88XnDxbyRo3x+klpx9Yf7
3wOj77i7OhyfhieAd9UAWsDRkBA8NaHGKsKg9pyFG4YGGfn+znf/YRHCFG2HjCy0
+UunZVJvKOM=
=tphK
-----END PGP SIGNATURE-----
--
SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/
Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
