I am currently still in the design stage.
What input types need to be supported in a OS.
I currently Have these.
Aux - Auxiliary, Undefined input.
Block - ROM's, HDD's, and friends.
NULL - The Blackhole in every OS.
Parallel - PCI, Centronics.
Serial - USB, PCIe and RS232.
These are stubs on which drivers can latch on for I/O operations.
I couldn't find any information on the wiki about this directly, and i would like to know if there should be more I/O types.
input devices stub
-
- Member
- Posts: 81
- Joined: Wed Nov 09, 2011 2:21 am
- Location: Behind a keyboard located in The Netherlands
Re: input devices stub
I have no "NULL" input device, no aux input device, and I generally do not consider everything as "input" or "output" devices. I've defined one interface per device-category.
Something like this:
1. File IO (the file API has positioning, time and size methods that cannot be considered part of a "stream" API)
2. Directory handler (doesn't treat directories as files)
3. Keyboard support (which includes press/release information and scancodes not part of a "stream" API)
4. Mouse (and touchscreen)
5. Video
6. Audio (audio input cannot be considered a "stream" either, as it needs to be accessed as a continous stream with an inherit sampling frequency)
7. Network card API (this is a packet API, but also contains connection information and package headers that are not "stream" oriented)
8. TCP/IP (I do not regard sockets as input/output "streams", and I have the "push" method that is not "stream" related)
9. IPC (operates locally and over network with the same API, uses a message view with send-reply)
10. USB API (USB is a mixture of block and stream interfaces)
11. Serial port (which includes USB serial port emulation, and have things like DTR, RTS, CTS and RI which doesn't fit the "stream" view)
Something like this:
1. File IO (the file API has positioning, time and size methods that cannot be considered part of a "stream" API)
2. Directory handler (doesn't treat directories as files)
3. Keyboard support (which includes press/release information and scancodes not part of a "stream" API)
4. Mouse (and touchscreen)
5. Video
6. Audio (audio input cannot be considered a "stream" either, as it needs to be accessed as a continous stream with an inherit sampling frequency)
7. Network card API (this is a packet API, but also contains connection information and package headers that are not "stream" oriented)
8. TCP/IP (I do not regard sockets as input/output "streams", and I have the "push" method that is not "stream" related)
9. IPC (operates locally and over network with the same API, uses a message view with send-reply)
10. USB API (USB is a mixture of block and stream interfaces)
11. Serial port (which includes USB serial port emulation, and have things like DTR, RTS, CTS and RI which doesn't fit the "stream" view)
Re: input devices stub
Strictly speaking, do you need a null device? I would assume this is to ape posix in which case it is optional. Also do network devices have their own category, eg packet and if so isn't this where usb belongs, or are you placing this as an abstraction on top of serial and block?
Re: input devices stub
It depends on your objective, for me, my first kernel only need to support serial port for debug purpose and network IO. There is no keyboard, mouse, or even visual display, all things go via network only.CrypticalCode0 wrote:What input types need to be supported in a OS.
-
- Member
- Posts: 81
- Joined: Wed Nov 09, 2011 2:21 am
- Location: Behind a keyboard located in The Netherlands
Re: input devices stub
I said stubs for a good reason this is where the I/O goes ontop of it.brain wrote:Strictly speaking, do you need a null device? I would assume this is to ape posix in which case it is optional. Also do network devices have their own category, eg packet and if so isn't this where usb belongs, or are you placing this as an abstraction on top of serial and block?
It's a entry point this can be handled in a wide range of things, keyboard and mouse for my OS would be most of the times a serial connection, this has to do with the fact that USB HID can co-exist on a system with PS/2 and I still have systems with the keyboard getting connected by a DIN connector!
I would like to design something universal, hence the AUX and the NULL.
I am not aiming to be posix compliant but when it helps i will not work around it.