The Linux Lab Project's LDDK Package

                  version 0.1-alpha
              (raw evaluation package)
---------------------------------------------------------

What is LDDK ?
==============

LDDK stands for 'Linux Driver Development Kit' it should
help to minimize the development time for a hardware 
driver module significantly and provides a 'standard' 
driver interface that should be compliant to the MFC-API
sometime in the future.

Currently the only tool available is the DDL compiler 
and a set of driver templates. Some other tools
as a Graphical User Interface and a Language interface 
generator for python, tcl or other languages are planned,
but due to the permanent lack of my time......

What is DDL ?
=============

DDL is a simple 'Driver Description Language'.
ddl2c, the DDL compiler takes a driver 
description file and generates a complete driver 
source tree automatically, including Makefiles, libraries
includes and all necessary code that should be ready to compile.
The DDL can contain all necessary C-code or can be used
to import foreign source files into the source-tree.

How does it work ?
==================

The DDL consists of a ddl-parser and a template 
preprocessor that replaces '%<token>' macros with 
some useful code. The templates are normal ascii
files that are used to build .h or .c or Makefiles [*.

[* Currently the macro language is very primitive so
the biggest part of the code generation is hardwired.

Features:
==========

Currently some simple driver types can be generated:

- simple global driver modules
   a global modules uses one single major number
   for all its methods (open,close,read,write etc)

- simple submodule driver modules
   this are submodules that can be acessed using 
   minor numbers, if you have a card with different
   chips for example you can have one submodule driver
   for each functional unit (with MFC-API this is called
   'atom' ). each 'atom' can have its own
   methods.

Inlined C-Code (codesections) is included in /{ .. }/ pairs, comments
within codesections will be dumped untouched.

Ioctl functions and corresponding user-library functions
are generated automatically. Imagine you want to have
a ioctl function to set a mode in one chip register.
The corresponding function would be

   Set_Mode( int port, int mode ){
      /* do something useful */
   } 

Now let's see how it looks in DDL for a module 
named "Test":

   ioctl {
	func Set_Mode( int port, int mode ) /{
		/* do something useful */
	}/
   }

this statement will generate a ioctl function SET_MODE
and a corresponding library function that can just 
be called with:

  Test_Set_Mode( fd, port, mode );

while fd is the file descriptor and port and mode are
the arguments. The library function packs all arguments 
into a structure Set_Mode_arg_t and calls ioctl() with 
it. Inside the driver the struct is area-checked and
unpacked [*. 

[* Currently pointers are not unpacked recursively so you have
to do the area-check and the memcpy_fromfs by hand.


Standard features:
===================

Each driver has debugging code compiled in that can 
be enabled using the -DDEBUG compile-time option.
The debugging level can be set using the dbgMask=<level>
option with insmod.

TODO/Planned features:
=================

- automatic generation of manual pages
- a more flexible DDL -> a more flexible 
  macroprocessor
- code templates for PCI/ISA-dma code and interrupt
  serviceing
- a register layout facility that generates flexible
  register access functions.
- more documentation and example files
- a garbage collector (see below)
- intrinsic configuration code would be nice

BUGS/CAVEATS:
==============

Currently the code for the ddl compiler is very messy
and many string buffers are hardcoded to fixed length (without checking of course). 
So expect some segfaults :) if your
inlined code segments are getting too long.


Please feel free to help me on this project..



now have fun
(givin '95 another kick :) )
cheers
clausi
(clausi@chemie.fu-berlin.de)