OSDev.org

Hello coderz.

I'm just wondering what kind of interface i could give to my driver system. The unix-like (open/close/read/write/ioctl) seems too limitated to support nowadays devices like framebuffered display, streaming audio, etc.

in another sense, i would like to find some way to "clusterize" the drivers in some generic-classes so that the learning curve would be better, but i can't imagine to consider a network card like a block/char device...

http://clicker.sourceforge.net/wspace/d ... evkit.html should give you a few more infos about what's troubling me

any trouble shooter ?

ioctl's are the most obscure stuff in the unix world...but, combined with a file system interface to use memory and devices, it is (for me, at least) one of the best and powerful ways to get around stuff like device drivers.

I suggest a mixed solution. Low level ioctl's drivers for every
interface, wrapped around by a generic set of classes to handle devices. Each new device driver could "extend" or "implement" an abstract or virtual generic device driver class.

If a user needs to interact with a device, he/she would
request this object to the operating system, so the user would access the generic device driver api, wich in turn uses a set of predefined ioctl calls to interact with the device or the operating system...

You'll basically need the char/block/stream approach for
the generic device driver class. But each new object
implementing this class (literally, each device driver) can
override the in() or out() or whatever methods you put in
there with its own functionality.

there are some efforts to write some kind of portable-and-generic base code to write drivers that can work in linux AND windows at the same time. unfortunately, i don't remember the names for these projects