Driver managment

[KieranFoot]

Hi guys, im just writing a driver system for my os (MeganetOS3).

At the moment im using a structure which contains fn pointers to .read, .write and a multi function.

The driver r/w functions follow

void ???.read(uint start, uchar *buffer, uint length);

the multi function is as follows;

uint ???.mf(uint fn, uchar *buffer, ..);

i was just wondering how you guys have implamented driver functions???

[Pype.Clicker]

in clicker, each device driver provide a set of services. The access to block device (giving a block id and a buffer), for instance is a service and receiving packets is another one. Each service comes with its own interface that tells what the driver has to implement.

this come from the observation that not everything is a file, unlike what Unix tries to make us believe: character devices (in unix sense) such as keyboard or mouse cannot be fseek'd ... mass storage media require a position for virtually every read/write and won't support read/write of sizes that are not multiple of block size. Video devices typically aren't read/written at all: they're simply mapped to memory and network cards yet behave in a different way.

So, so far, different services have been identified: block, input, display, network and comm (for point-to-point communications such as RS232, IRda and the like).

A last category of driver exists in Clicker (a thing that comes from Mobius): the BUS driver, responsible for scanning a specific bus technology and reporting available devices.

[distantvoices]

The driver stuff has caused me some trouble too. Currently, each driver provides a set of known commands (which are simply Message Types) and as f. ex. character/pointing devices behave completely different compared to block devices (you can wait till getting grey hair ere something arrives whilst reading/waiting for input on a character device like keyboard/mouse) the interaction with the other parts of the system needs to be laid out in a completely different way.

Thus, for character devices, I've chosen to give delayed reply in async. manner. The file service (which is responsible for that stuff too) records an input request on a given console. as soon as input from that console comes along, it passes the input to the waiting thread and sends a reply.

Networking stuff is odd in all ways. You can regard your nic as a source of events like your other hardware, but you need to tend to it especially.

So, I have for my network stuff: driver files, which export symbols, which are taken by the net service and called by means of indirection structures (netif interface data) Each driver becomes an input and an output thread. They have: init, up, down, output,input functions.

Needless to say that getting a proper network stack planned and developped is like developping a kernel - really brain exhausting in the beginning. But once you've tied together all the loose ends, it merges to some beautiful kind of stuff. *gg*

Besides, there's calls like iocntl & fcntl which I've also incorporated in BlueIllusionOS just for the fun of it.

For your consoles you might think about an escape char mechanism for submitting commands. They stick in the same stream of output, the console driver takes the stream and checks whether there's escape stuff to treat. Easy stuff.

The more, I recommend you think early about some kind of database where to record all drivers/device/properties relations so one can easily take a record set and work with it. Having to query a dozen of services to get info about a device is tiring. Yeah, I have missed to plan this in the early stages. I'm a sloppy hog in this regard, I admit it.

stay safe.

[Pype.Clicker]

So, I have for my network stuff: driver files, which export symbols, which are taken by the net service and called by means of indirection structures (netif interface data) Each driver becomes an input and an output thread. They have: init, up, down, output,input functions.

yep. it might of course not worth the price, especially on an architecture such as x86 and with a generic-purpose OS, as time goes, i'm more and more attracted by the idea of "building" code on load time rather than using indirections. E.g. "binding" threads together to form a specific chain, or written code for interrupt service routine from bits of code each 'component' provided (yes, i know there is something alike in Windows NT ... thanks for having thought i might want to know it )

Needless to say that getting a proper network stack planned and developped is like developping a kernel - really brain exhausting in the beginning. But once you've tied together all the loose ends, it merges to some beautiful kind of stuff. *gg*

;D goto NickStacky.shelf and retrieve "Computer Networks: System Programming Approach" ... you might enjoy it

Besides, there's calls like iocntl & fcntl which I've also incorporated in BlueIllusionOS just for the fun of it.

aaaargh! no! ...

The more, I recommend you think early about some kind of database where to record all drivers/device/properties relations so one can easily take a record set and work with it. Having to query a dozen of services to get info about a device is tiring. Yeah, I have missed to plan this in the early stages. I'm a sloppy hog in this regard, I admit it.

true. seconding that ... "devices.vga0.config.modes.*" listing all the available video modes and "devices.net.*" listing all the network card, altogether with the same interface is a huge needle removed from your foot (french proverb)