[SOLVED] What Is The Best Way To Develop Drivers?

[CorkiMain]

I'm starting to work on drivers for my OS. For example, right now I'm working on an eMMC driver. I'm wondering, what's the best workflow for writing drivers for a new OS? My OS is still really basic, some features it has are printing, memory allocation, interrupts, exception handling, and threads. The OS runs on Arm64 architecture. I've been emulating with QEMU and debugging with GDB.

Right now, my plan of attack for writing drivers is:
1. Read specifications
2. Write driver code
3. Put OS on hardware
4. Use print statements to see what parts of the driver work
5. Fix issues based on the print statements
6. Repeat steps 3-5 until the driver is complete

I'm pretty new to OS development and curious if there's a better/faster way to write drivers, or if this is how it typically goes. I appreciate any advice.

[eekee]

You can write a GDB server into your kernel and connect to it over serial or ethernet, if you have one of those drivers already. If you want examples, Linux FreeBSD and NetBSD support it already, though the remote program is kgdb rather than regular gdb.

[sh42]

I'm starting to work on drivers for my OS. For example, right now I'm working on an eMMC driver. I'm wondering, what's the best workflow for writing drivers for a new OS? My OS is still really basic, some features it has are printing, memory allocation, interrupts, exception handling, and threads. The OS runs on Arm64 architecture. I've been emulating with QEMU and debugging with GDB.

Right now, my plan of attack for writing drivers is:
1. Read specifications
2. Write driver code
3. Put OS on hardware
4. Use print statements to see what parts of the driver work
5. Fix issues based on the print statements
6. Repeat steps 3-5 until the driver is complete

I'm pretty new to OS development and curious if there's a better/faster way to write drivers, or if this is how it typically goes. I appreciate any advice.

I'd see if you can get some hardware with good serial out. Also printing to screen might not be super reliable, so it might be nice to log to disk in some way so if the system crashes you might have some logs on the disk still up to the point it crashed.
You don't need anything fancy there, maybe just a buffer at the end of disk if you don't have a filesystem yet. Also, log the same messages out over serial. A lot of mainboards come with the option to connect serial so that might yield a similar log that's not reliant on the system still being up to read the log printouts. drivers can triple fault you etc., so prints to a screen won't be useful in all cases.

Also, between step 1 and 2, i'd try to create a data-model and specify your driver based on the notes you took while reading the specification. you'd not want to trial and error drivers for the most part, as errors will likely crash your system. This will be bad for your hardware. QEMU is more forgiving. You can also create devices for QEMU that respond like your actual device, to try and write the most things in QEMU. if your driver is specified correctly, you can also write the device it interacts with.

This might help to add new devices for qemu in such a scenario: https://airbus-seclab.github.io/qemu_blog/devices.html

[CorkiMain]

Thanks for the advice! I'll give everything here a try when I get around to it