Device organization in microkernel...

[distantvoices]

Ok. It's time for me to figure out how to design the device abstraction.

At the moment, I have just one device to read from/write to - the video device (it includes keyboard handling). the abstraction is simple: printf for writing and scanf for reading data.

But this kind of abstraction doesn't satisfy me for a process wanting to read/write to console has to issue a get_console() call to get a virtual console assigned to. This happens immediately after the start of the process.

This is way too ... direct. Of course, the device has to be opended before, but I think, there has to be one more level of abstraction: to assign a Name to the device: say console1, console2,console3,... and in runtime lib, at process startup, I want to have one such device opended (like a file ...) so that one can read from it and write to it ( in printf and scanf). It would remain a transfer of buffers. In my actual implementation, the video driver does the assign-console-to-task and other console management stuff.

And so, I want other devices be accessible by a name given to them upon registration of the driver with the file system, and the devices will be added to /dev. Of course, some devices will require more specific functions than open/close/read/write/ioctl.

man ... that's complicated.

[Therx]

My device organisation is fairly simple.

/ - Root of VFS
: - Driver Root

eg
:hda1/fat/docs/test.txt - File docs/test.txt
:eth1/tcpip/80/ - Port 80 over TCP/IP

As you can see this follows a pattern of driver, object. This allows any object to be used of any device.

eg.
:vga/tcpip/80/ - Would direct all the encoded packets to the screen for testing purposes.

The GUI or CLI would be :vga/gui or :vga/cli.

If an app wants to directly use the hardware it can (if it has permission) ommit the object :lpt1

The / VFS can be mapped to absolutely any device

eg.
/ -> :hda1/fat
/sys -> :/hda2/ext2

The drivers must provide read, write and isr routines. And the objects open, close, read and write. To avoid conflicts of drivers linked into the kernel the functions are prefixed with the drivers name and an underscore. For the driver to make its self known to the kernel it simply fill a predefined structure with pointer to its functions and calls the dm_add function. The DM allows as many drivers to share IRQs as they want but the driver must be able to tell whether it is IRQ for itself or for other hardware. The only unavailable IRQ is number 0 which is used to run the task scheduler.

Hope this gives you some ideas.

Anyone see any major probs

Pete

PS I realise the read, write is a bit restrictive but I want ALL drivers to go through the same interface instead of having on for net drivers, one for printers etc.

[Pype.Clicker]

In Clicker, any device belongs to one device family, which tells what kind of operations can be performed on it. For instance, the disk family will offer read(block_index,block_nr,buffer) and write(block_index, block_nr, buffer) and is guaranteed to announce the block size and maximal block index in the information structure about the device.

the character family, instead, could offer get_char(), put_char(), get_line() and put_line() and you can receive "end of file" through them ...

Other families like video (framebuffer), network (send/receive packets) or sound (with time constraints) will be used aswell.

If a driver needs another one (for instance, implementing /dev/hda2 on top of /dev/hda), this is done by making the new driver to be a client of the earlier one.

I'm unsure about therx's ":vga/tcpip/80" for a few reasons:
- vga/gui and vga/cli both address vga as a framebuffer (afai can imagine), but vga/tcpip will rather expect "vga" to offer a console-like display (unless what you wanna do is painting pixels with packets, but i think that's not the point here).
- TCP/IP will send a SYN packet and expect a 'SYN+ACK'. How will VGA send SYN+ACK ?

Now, even saying ":eth1/tcpip/80" looks strange to me: why must the application know that ETH1 is to be used ? what if you want to listen to port 80 on both ETH0, ETH1, SER0 and RING0 -- or on every available network interface ?
Also, ":eth1/tcpip/80" works fine for listening sockets, but what about client sockets ? will you have ":eth1/tcpip/139.165.223.16/80" ?

Don't take me wrong, Pete: having a complete naming for devices is certainly a good thing, but maybe the naming don't need to be "that" explicit. If you have a virtual device, it's not necessary to see in the name what physical device it will use, is it ? for instance, the choice of what :network_interface/eth? will be used by :tcpip/socket/12 can be resolved at the time of socket/12 creation. And all we need is a unique identifier for the socket, not necessarily the target destination you'll use (remember several sockets can be bound to the same destination provided that their source ports or source IP are distinct

[Therx]

You're right I hadn't thought it through. I had designed it when the only object driver I was considering was a filesystem for which my plan would work perfectly.

Thanks

Pete

[distantvoices]

oy, the socket thing ]:-> ...

hm ... device families ... the approach sounds good. Isn't this somewhat vaguely resembling to major/minor numbers? f. ex. character device console: Major 1/minor 1-4 ? And cant block devices be operated in a kind of stream mode, like character devices?

hmmmmmm.... pype, wouldn't share /dev/hda and /dev/hda1 the same device (a hard disk f. ex.). Then, hda1, is just another partition, isn't it, but the other things are the same? blocks adressed by chs or lba? May be I didn't undrstand something in your idea? Then reading is an art i 'd learn again ];->

[Pype.Clicker]

actually, "system.device.disk.ide0.master" is the equivalent to Linux://dev/hda. It's a physical block device.

Virtual block devices (partitions, for mosts) are referred as "system.device.disk.<filesystem>.<uniqueID>" like "system.device.disk.FAT32.C" for /dev/hda1 ...

they translate blocks into 'physical' blocks. But they could have distinct block size (using cluster size as block size, for instance) and may provide whatever virtual/physical blocks mapping, thus they're not limitted to partitionning, but can also be used to implement RAID policies, or services like LVM ...

And, well there is a similarity in goals for major numbers and device families, but families implies a specific interface for the device. (while i'm unsure about major numbers) and include network interfaces (while eth0 has no major/minor number iirc)

[Tim]

Mobius has something similar: devices are organised in a tree structure. For instance, a partition will be a child of a disk, which will be a child of an ATA controller, which will be a child of the ATA bus, which will be a child of the PCI bus.

So the full name of a partition might be:
[tt]/System/Devices/pci/pci:0:7:1/primary/master/1[/tt]
This identifies the first partition on the master disk on the primary IDE controller on the ATA controller (at PCI bus 0, device 7, function 1), on the PCI bus.

Obviously this is rubbish for every day use. "I want to mount a hard disk -- what path do I use?" "/System/Devices/..." "OK, I'm bored now."

So Mobius has an alternate naming system, in parallel with the bus/device structure. Devices are also organised by their PCI class, in a Classes directory off /System/Devices. So the disk I mentioned above would also be available in:
[tt]/System/Devices/Classes/volume1[/tt]

Not only does this simplify naming, it also makes it easy to generate lists of all devices of a particular class. The Volume Mount program might display a list of all volumes available on the computer; to do that, all it needs to do it list [tt]/System/Devices/Classes/volume*[/tt].

Unfortunately, the contents of the Classes directory can change between reboots, as devices are added and removed, or even as devices are hot-plugged (although Mobius doesn't support any hot-pluggable buses yet). So the Volume Mount utility would need to translate the class-based device name to the full name before it saved it to the config file.

[distantvoices]

first, thank's for the replies and for the inspiration

So, it would lead to device management separated from file management, thus abandoning the classic unix approach of leading device accesses through the file system.

I'd have to create a kind of device management process which is responsible for keeping device tables up to date - and informs the file system process about available block devices (f. ex. fd0, hda, hdb...), and loads/wipes out drivers at request. Hm ... it is a protocol and policy question how to handle it.

What to do then with the few driver tasks I compile into the kernel image to have the barebone minimum of drivers at hands to get the system running? register them as soon as they receive an according message from the device management?*hum hom ... says treebeard*

[Pype.Clicker]

some similar thread posted earlier (uh ... by myself ::) )