Types of devices

[0Scoder]

Hi. I am currently in the design of my OS working to define standard interfaces between devices and programs, with the target of making things more flexible (for example, in unix every program can access each disk, as it is mounted into one filesystem). To do this I will need to put devices into rough groups (i.e block devices, etc), each of which will have a standard interface which can allways be used to access it.

So far I have been able to think of the following:
- Block devices (devices that work in blocks of data refferenced by sequential numbers)
- Heirarchical devices (ie filesystems)
- Bitmap devices (ie monitors - that display graphics in bit mapped form)

Are there any further abstractions anyone can add (I want to have as few groups as possible)?

Thanks,
OScoder

[Solar]

Streams, for example video / audio capturing devices, where you don't have random access. Filesystems and other hierachies are usually superimposed on block devices, not a device type of their own.

[Pype.Clicker]

you may add "ioctl" devices ... that is, that kind of device that do not really follow a "character device" abstraction but rather have series of commands that you can send to manipulate the device proper (extremely frequent in embedded systems, and still present on some PC hardware).

Network devices are quite specific too. They're not delivering data "character by character" but rather "packet by packets" and unlike block devices, packets may have variable sizes. They're quite specific too by the fact you cannot "request" for a packet like you request for a given block: you just get what's coming in ...

[evincarofautumn]

Offhand, I can think of a few:

• Block devices
  • CD
  • FD
  • HD
  • USB media
• "Bitmap" devices
• Controllers & Controller-handled devices
  • Floppy
  • Graphics
  • IDE ATA/ATAPI
  • PCI
  • Audio
  • PIC
  • ...
• Human interface devices
  • Keyboards
  • Mice
  • ...
• Network devices
• Serial ports
  • COM ports
  • ECP printer (LPT1, 2)
• Case buttons

It all depends on personal preference. You could just lump everything together with a union of the data that these devices return (or should handle) and a big enum of the types of devices available to the system api, e.g., a pair of generic [tt]dout[/tt] and [tt]din[/tt] streams.

On a related note, I haven't gotten around to figuring out exactly how to detect all of the devices available to me, so Sensory has pretty much no significant device-handling code ^^. I was thinking that devices would be rooted at [tt]:[/tt] and be indexed by 32-bit type signatures (e.g. [tt]:BLOK:HDSK:IDE1[/tt]). Thoughts?

[0Scoder]

I was thinking that devices would be rooted at : and be indexed by 32-bit type signatures (e.g. :BLOK:HDSK:IDE1). Thoughts?

That's kindof similar to the way I want to work, I have the abstraction that everything is an object. Objects are arranged in a heirarchical structure, so you could reffer to a disk like so: devices.data.ide1 or devices.display.bitmap.monitor1. Each object has a type, so objects you could interface with in similar ways have their own type number. So, if an application knows how to interface with a hard disk, that means it will also be able to interface with a USB drive (aside from the device-specific configuration options). Each object has 'functions' that I reffer to by a :.

For example, to interface to a data device you would send the object request:
devices.data.hd1fat.homes.OScoder.interstingdocument.0:get(1)
And the hd1fat device would get block 0 of this document and place in onto IPC stream 1. All data objects have a 'granularity' as a standard for getting their block size (gettable by object:granularity())

Filesystems and other hierachies are usually superimposed on block devices, not a device type of their own.

Incidentally though, the interface for drivers of both (unless you are in an exokernel system) are rather similar. For both disks and filesystems, you hand them an address or filename to reffer to the resource you want, and they pass you back data. Thus, they can be given the same type. This means that you could say, use a text editor to edit your MBR, and things like that (if you had permissions.

Thoughts?

[Kemp]

devices.data.hd1fat.homes.OScoder.interstingdocument.0:get(1)

I'm guessing that would be passed as a parameter to a function (at least if you're coding from a language like C) which parses the request, I can see such calls being insanely long and prone to typos.

[Solar]

devices.data.hd1fat.homes.OScoder.interstingdocument.0:get(1)

I hope you are seriously considering the use of handles, so that I could do

DataDevice mydisk = devices.data.hd1fat;
Document mydoc = mydisk.OScoder.interestingdocument.0;
...

[0Scoder]

I hope you are seriously considering the use of handles, so that I could do

Certainly considering it now! Probably at the library level (the request protocol I am working on would make this quite simple).

Thanks for the advice,
OScoder

edit:
note, at the usermode level I also intend having a 'url' library available, which should simplify things (so people could refference to a website by typing 'http://www.mega-tokyo.com/index.html', without having the handle the complexities of refferencing to objects directly.