It's Time for Operating Systems to Rediscover Hardware

Re:It's Time for Operating Systems to Rediscover Hardware by Const-me on Wednesday September 01, 2021 @07:31AM (#28378503)

> the complexity of the codebase to talk to the USB device was around the similar level of complexity to the entire preemptive multitasking operating system the students were building

For the complete USB stack, that's very likely. However, for minimal code needed to read keys from keyboard USB shouldn't be that bad.

These students only need USB 1.1. They don't need to support bulk transfers (USB protocol has 2 distinct transports, one low latency another one high throughput). They don't need to support USB hubs between computer and the keyboard. The only device type they need is HID.

USB consortium wouldn't allow to call that protocol USB due to the missing features, but it's good enough for education purposes.

[ Parent | on HN ]

Re:It's Time for Operating Systems to Rediscover Hardware by Cthulhu_ on Wednesday September 01, 2021 @08:07AM (#28378787)

It's still a LOT more to think about and that they have to filter out when developing it though.

[ Parent | on HN ]

Re:It's Time for Operating Systems to Rediscover Hardware by Const-me on Wednesday September 01, 2021 @08:51AM (#28379193)

The professor could implement these boring lower-level pieces in a library which fires couple callbacks, one on connect/disconnect to provide two descriptors for HID device and their reports, another one for handling the HID report packets.

BTW, USB specifies a small subset of HID interface called “boot interface”. It’s normally consumed by UEFI firmware who needs mouse and keyboard for the setup GUI which runs before OS launches. The subset only supports basic keyboards and mice.

[ Parent | on HN ]

Re:It's Time for Operating Systems to Rediscover Hardware by bluGill on Wednesday September 01, 2021 @09:28AM (#28379534)

Then it isn't write your own OS from scratch. The constraints of the library will force your implementation around it, even if you think you have a better idea.

[ Parent | on HN ]

Re:It's Time for Operating Systems to Rediscover Hardware by Const-me on Wednesday September 01, 2021 @10:22AM (#28380211)

This project https://github.com/Const-me/Vrmac implements unified keyboard+mouse input API over 3 distinct lower-level APIs: Win32 messages, XCB packets, and Linux raw input. Here’s for raw input: https://github.com/Const-me/Vrmac/tree/master/Vrmac/Input/Li... All 3 have unique quirks, yet I would not say they significantly affected the rest of the library.

I think for the USB in that OS, a C API with intentionally very narrow scope would be OK for the job.

The main reason why the real-life code is so complex is that scope being very wide. We have USB 2 and 3, mass storage, two-way audio, cameras and GPUs, hubs and composite devices, numerous wireless protocols on top, OTG, power delivery, power saving features, and more.

[ Parent | on HN ]

Re:It's Time for Operating Systems to Rediscover Hardware by xnormal on Thursday September 02, 2021 @02:15AM (#28389187)

A well-written library can effectively expose a simpler hardware device with minimal assumptions

[ Parent | on HN ]

Re:It's Time for Operating Systems to Rediscover Hardware by bluGill on Thursday September 02, 2021 @09:01AM (#28391511)

Sure, but even one assumption limits innovation. Even if the innovation is stupid, learning the hard way is useful, so I want at least one student every few years to try that stupid thing and then from personal experience tell the others why it didn't work out.

If we were talking about a serious project there are a lot of best practices that should be rarely (and then only carefully) questioned, but for something intended to be thrown away at the end of the semester challenging best practices is a great way to learn.

That said, PS/2 is a simplifying assumption as well.

[ Parent | on HN ]