3 ms·

Warning: I have no idea about systems programming. I understand that the amount of lines of driver code comes from the variety of devices. But still, it looks

by iagooar 11y ago

Warning: I have no idea about systems programming. I understand that the amount of lines of driver code comes from the variety of devices. But still, it looks completely unbalanced, when compared to the kernel code itself. So I have some questions here: 1) Shouldn't there be common interfaces / abstractions for most of the devices? 2) If they exist, could they be improved somehow? 3) A bit unrelated, but how fun / interesting is it to develop driver code?

bluecmd 11y ago
There are. USB, SATA, SCSI and such share a lot of code between the drivers - but drivers are huge.
- k__ 11y ago
  I would guess, that most of the size comes from history. Like, once it seemed a good idea to have it like that and later people found out there are a bunch of things missing. Now many of them have to be implemented on the driver side over and over again.
  - mrob 11y ago
    Have you read the USB specs recently? They're publicly available here: http://www.usb.org/developers/docs/ http://www.usb.org/developers/docs/ Just making a standards compliant implementation takes a huge quantity of code. And with a standard this complex people inevitably get it wrong, so you'll need workarounds for all the broken devices too.
    - tracker1 11y ago
      Not just with hardware interfaces, but even in pure software... I wrote an LMS that the core of which was used by a fortune 100 company, and a few airlines for nearly a decade... I literally left out about 1/3 of the SCORM spec, and implemented one piece badly... it wasn't until about 8 years in that the missing piece was even an issue, and the part I got wrong never became an issue. In the end, you understand as much as you can, implement what you have to, and do your best to get through it... and even then, someone will mess things up on some end or another... to this day, I'm surprised that SCORM was synchronous... hell, it feels like they're half the reason XHR has a sync option. I feel the same way when looking at terminal emulators... sigh, so many things to implement to get something useful, even if you're only looking to get a small subset working.
thechao 11y ago
The header file for compatible OpenGL 4 will run to 50kloc. The jump table and normalization routines will be twice that. That's more LOC than the Linux kernel, and all it does is sigbus.
gjulianm 11y ago
1/2. Yes there are. Network devices, file systems... most of the things that could be abstracted are done. However, take into account that every device has its special quirks and configurations. Only very generic devices can have generic drivers. But once you get to specific devices, you need specific drivers that can deal with special features and non-standard communications. See for example the number of vendors of ethernet drivers (https://github.com/torvalds/linux/tree/master/drivers/net/ethernet https://github.com/torvalds/linux/tree/master/drivers/net/et...). And that is just a small part of the code. 3. Interesting? A lot. You get to learn how do low-level parts of your system work, deal with complex structures and interactions between kernel/hardware/userspace and. But the most interesting thing is the programming ability you need. You have to really understand the code, be able mentally follow the execution paths (which are not simple, believe me) and write as few bugs as possible. Why? Because you don't have many tools. No debuggers, no unit tests... My main debugging tool is a set of debug macros that print to the kernel log. Debugging is a real pain in the ass and crashes can lead to a system restart, so I have to try to get it right as soon as possible. I hope that also answers the "fun" part ;)
astrobe_ 11y ago
1) They do, 2) ... but the meat of a driver is putting the right values in the right registers of some chip, and sometimes work around bugs in said chip, or sometimes take into account that popular variant that's almost the same that the original but not quite... It takes a lot of boilerplate code. 3) It depends on your definition of fun. A driver by definition is a middle man between the OS and the hardware; so programming there is a lot about doing what you're told (and sometimes get punished harshly because you misunderstood something), either by the kernel documentation or by the datasheet of the chip you talk to.
- deleted 11y ago
  [deleted]
notalaser 11y ago
1. There are, but they only exist in software. You have to write a different glue layer for virtually every device. And sometimes the device's model doesn't really fit your driver's. 2. Not... really. Standards are supposed to do that. Many hardware manufacturers don't really implement them in a proper manner, and "whoever designed this flash controller should die a slow, painful death" is not something users care about. 3. If the device is well-documented and relatively standard-abiding, it's extremely fun if you're passionate about it and relatively painless if you're not. Otherwise, it's about as fun as digging a tunnel under Mordor with a toothpick.
- tracker1 11y ago
  Even then, most standards have parts that are obtuse to say the least, others that aren't really needed for a given application and others that are just open to some interpretation or otherwise not clearly defined... In the end, people tend to do the best they are able to in a given situation. Often that means ignoring some parts, and making assumptions for others so that your product can ship instead of waiting over a year for a standards body that might clarify something.

by iagooar 11y ago

bluecmd 11y ago

There are. USB, SATA, SCSI and such share a lot of code between the drivers - but drivers are huge.

k__ 11y ago
I would guess, that most of the size comes from history. Like, once it seemed a good idea to have it like that and later people found out there are a bunch of things missing. Now many of them have to be implemented on the driver side over and over again.
- mrob 11y ago
  Have you read the USB specs recently? They're publicly available here: http://www.usb.org/developers/docs/ http://www.usb.org/developers/docs/ Just making a standards compliant implementation takes a huge quantity of code. And with a standard this complex people inevitably get it wrong, so you'll need workarounds for all the broken devices too.
  - tracker1 11y ago
    Not just with hardware interfaces, but even in pure software... I wrote an LMS that the core of which was used by a fortune 100 company, and a few airlines for nearly a decade... I literally left out about 1/3 of the SCORM spec, and implemented one piece badly... it wasn't until about 8 years in that the missing piece was even an issue, and the part I got wrong never became an issue. In the end, you understand as much as you can, implement what you have to, and do your best to get through it... and even then, someone will mess things up on some end or another... to this day, I'm surprised that SCORM was synchronous... hell, it feels like they're half the reason XHR has a sync option. I feel the same way when looking at terminal emulators... sigh, so many things to implement to get something useful, even if you're only looking to get a small subset working.

thechao 11y ago

The header file for compatible OpenGL 4 will run to 50kloc. The jump table and normalization routines will be twice that. That's more LOC than the Linux kernel, and all it does is sigbus.

gjulianm 11y ago

1/2. Yes there are. Network devices, file systems... most of the things that could be abstracted are done. However, take into account that every device has its special quirks and configurations. Only very generic devices can have generic drivers. But once you get to specific devices, you need specific drivers that can deal with special features and non-standard communications. See for example the number of vendors of ethernet drivers (https://github.com/torvalds/linux/tree/master/drivers/net/ethernet https://github.com/torvalds/linux/tree/master/drivers/net/et...). And that is just a small part of the code. 3. Interesting? A lot. You get to learn how do low-level parts of your system work, deal with complex structures and interactions between kernel/hardware/userspace and. But the most interesting thing is the programming ability you need. You have to really understand the code, be able mentally follow the execution paths (which are not simple, believe me) and write as few bugs as possible. Why? Because you don't have many tools. No debuggers, no unit tests... My main debugging tool is a set of debug macros that print to the kernel log. Debugging is a real pain in the ass and crashes can lead to a system restart, so I have to try to get it right as soon as possible. I hope that also answers the "fun" part ;)

astrobe_ 11y ago

1) They do, 2) ... but the meat of a driver is putting the right values in the right registers of some chip, and sometimes work around bugs in said chip, or sometimes take into account that popular variant that's almost the same that the original but not quite... It takes a lot of boilerplate code. 3) It depends on your definition of fun. A driver by definition is a middle man between the OS and the hardware; so programming there is a lot about doing what you're told (and sometimes get punished harshly because you misunderstood something), either by the kernel documentation or by the datasheet of the chip you talk to.

deleted 11y ago
[deleted]

notalaser 11y ago

1. There are, but they only exist in software. You have to write a different glue layer for virtually every device. And sometimes the device's model doesn't really fit your driver's. 2. Not... really. Standards are supposed to do that. Many hardware manufacturers don't really implement them in a proper manner, and "whoever designed this flash controller should die a slow, painful death" is not something users care about. 3. If the device is well-documented and relatively standard-abiding, it's extremely fun if you're passionate about it and relatively painless if you're not. Otherwise, it's about as fun as digging a tunnel under Mordor with a toothpick.

tracker1 11y ago
Even then, most standards have parts that are obtuse to say the least, others that aren't really needed for a given application and others that are just open to some interpretation or otherwise not clearly defined... In the end, people tend to do the best they are able to in a given situation. Often that means ignoring some parts, and making assumptions for others so that your product can ship instead of waiting over a year for a standards body that might clarify something.