On Thu, 31 Aug 2000, Christoph Egger wrote:
> The DDL-Compiler doesn't create any binary. No - the DDL-Compiler is
> principally a translator from DDL to C.
>
> A driver written in DDL, will be compiled in two steps:
>
> DDL -> C (done by the DDL-compiler)
> C -> binary module (done by the C-Compiler)
Yes. But, from what I understood of LDDK (I gave it a look yesterday), the
DDL compiler generates a (sort of) "driver stub" - conformant to the linux
kernel internal API. It generates open(), ioctl(), close() etc. functions.
This is not at all what I had in mind (I think). DDL aims at providing a
well-written and conformant driver.
I'd rather like to have a language that could help the device driver
programmer to write easily and concisely some of the repetitive (and
error-prone) parts of the driver code: the hardware register access
functions (and #define-d constants: mask, registers addresses, etc.). But
the programmer is still in charge for the entire organization of the
driver code (while something like DDL might help him in such a task).
So, I'd rather target a hardware description language than a driver
definition language. Btw, both ideas are probably not exclusive.
I'll try to work more on my idea this week-end and post a few
examples; because I find it rather uncomfortable to speak without examples
to give. Give me some time to clarify my ideas and explain them better
with a few good old VGA registers and some tentative syntax!
Finally, IMHO, the LDDK and DDL approach is tightly linked to the
targetted operating system (linux). Well, I may be wrong, but it's my
feeling.
Rodolphe
