6 ms·

I've written a lot of low level software, BSPs, and most of an OS, and the main reason to not write your own OS these days is silicon vendors. Back in the day,

I've written a lot of low level software, BSPs, and most of an OS, and the main reason to not write your own OS these days is silicon vendors. Back in the day, they would provide you a spec detailed enough that you could feasibly write your own drivers. These days, you get a medium-level description and a Linux driver of questionable quality. Part of this is just laziness, but mostly this is a function of complexity. Modern hardware is just so complicated it would take a long time to completely document, and even longer to write a driver for.

tanvach 1y ago
Yeah reverse engineering all the drivers is going to be a huge headache.
- markus_zhang 1y ago
  Sounds like super fun if I could be paid a bit for it. What is an easy gate task to get into “reverse engineering some drivers for some OS”? Second thought: I don’t even know how to write a driver or a kernel, so I better start from there.
  - wmf 1y ago
    Asahi Linux.
  - toast0 1y ago
    I don't know how you get paid for it, but if you want to write your own kernel, I'd start with an osdev tutorial. started with this one [1], but this one [2] has a promissing name... and I haven't really looked around. It helps to have a concept to guide you too, but you can certainly make some progress on the basics before you figure out what you really want to do. [1] https://wiki.osdev.org/User:Zesterer/Bare_Bones https://wiki.osdev.org/User:Zesterer/Bare_Bones [2] https://osdev.wiki/wiki/Multiboot1_Bare_Bones https://osdev.wiki/wiki/Multiboot1_Bare_Bones
    - markus_zhang 1y ago
      Thanks. I got all the resources covered. But I don’t have the energy to work on them as a side project any more. Alas! I wasted my younger days and hope you fare better!
      - saagarjha 1y ago
        Unfortunately, you are unlikely to be able to jump into just being paid to write an OS with no experience.
  - mastermage 1y ago
    Isn't that what low level does on his YouTube channel teach people to reverse engineer stuff?
    - spauldo 1y ago
      Mostly he seems to try to nail all the items on the "how to grow your YouTube channel" checklists. Clickbait sensationalist titles, exaggerated face on the thumbnail, etc. I have a rule that I don't click on any video where I can't tell the subject by the title, and that eliminated him from my watchlist a while ago. I wish the guy luck on becoming a superstar influencer, since that seems to be his goal, but he can do it without my help.
anikom15 1y ago
It’s entirely laziness.
- deleted 1y ago
  [deleted]
boredatoms 1y ago
Presumably if you’re meta you could pay the vendors enough to write drivers for any arbitrary OS
- rwmj 1y ago
  But is that a good use of Meta's money? Compared to making a few patches to Linux to fix any performance problems they find. (And I feel bad saying this since Meta obviously did waste eleventy billion on their ridiculous Second Life recreation project ...)
  - b112 1y ago
    I don't like Meta, but there used to be a time where big corp used to spend 30% of its budget on R&D. It's how we got all the toys we have now, R&D labs of big Bell and others. So please don't mock the spend. Big spends fail sometimes, and at least people were paid to do the work.
    - rwmj 1y ago
      It's just that it was so obviously going to fail, because there's no mass market for a product that you have to strap onto your face. You didn't need to spend billions to learn that. If they'd spent the money researching nuclear fusion or space flight or a new way to develop microprocessors, I would be cheering their efforts even if they had failed in the end.
    - crote 1y ago
      The difference is that organisations like Bell Labs and Xerox PARC were primarily tech-first: innovations were the result of very clever and creative people doing blue skies research. The most groundbreaking stuff shocked the world while it was still a hacked-together demo, and similarly the cost of failure was quite low. On the other hand, Meta's experiment is primarily CEO-driven. The outcome is predetermined, changing direction is not possible. Sure, clever engineers get to draw the rest of the owl, but that's not very useful when it turns out that everyone needs a horse instead. They are spending a fortune, but rather than getting 900 crappy ideas to throw away and 100 great ones to pick from for continued development, they are developing 1 technological marvel nobody is interested in.
mbac32768 1y ago
Yeah this. I tried to modify a hobby OS recently so it would process the "soft reboot" button (to speed up being rebooted in GCP) and it was so unbelievably hard to figure out how to support it. I tried following the instructions on the OS Dev Wiki and straight up reading what both Linux and FreeBSD do and still couldn't make progress. Yes. The thing that happens when you tell Windows or Linux to "restart". Gave up on this after spending days on it. The people who develop OSes are cut from a different cloth and are not under the usual economic pressures.
- gmueckl 1y ago
  I also think that they have access to more helpful resources than people outside the field do, e.g. being able to contact people working on the lower layers to get the missing info. These channels exist in the professional world, but they are hard to access.
- sitkack 1y ago
  The VMM on GCP has only really been tested with Linux. You are kinda wasting your time, the only way to make it work is to make the hobby OS Linux.
  - toast0 1y ago
    > You are kinda wasting your time, the only way to make it work is to make the hobby OS Linux. Not the parent, but of course they're wasting their time... That's the point of a hobby OS. I'm working on a hobby OS, and I have no illusions that it's most likely fewer than 10 people will ever run it, and less than 100 will hear about it, but it lets me explore some interesting (to me) ideas, and forces me to learn a little more about random pieces of computing. If I ran on GCP, I'd want the reboot button to work. That sounds useful. On the topic, I don't see why anyone would want to build a general purpose OS. There's enough already and even with the shrinking of hardware variety, there's a lot of stuff to support to make a general purpose OS work on enough hardware for people to consider using it. You can take Linux or a BSD and hack it up pretty good to explore a lot of OS ideas. Chances are you're going to borrow some of their drivers anyway, and then you'll end up with at least some similarity... may as well start there and save a lot of time. (My hobby OS has a custom kernel and custom drivers, but I only support a bare minimum of devices... (pc) console i/o, one real NIC, and virtio-net... that's all I need; I might add support for more NICs and more consoles later)
b112 1y ago
Modern hardware is just so complicated it would take a long time to completely document, and even longer to write a driver for. That's what's claimed. That's what people say, yet it's just an excuse. I've heard the same sort of excuse people have, after they write a massive codebase, then say "Oops, sorry, didn't get around to documenting it". And no, hardware is not more difficult than software to document. If the system is complex, there's more need to document, just as with a huge codebase. On their end, they have new employees to train up, and they have to manage testing. So any excuse that silicon vendors have to deal with such immense complexity? My violin plays for them.
- supermatt 1y ago
  > If the system is complex, there's more need to document It’s not first party documentation that’s the problem. The problem is that they don’t share that documentation, so in order to get documentation for an “unsupported” OS a 3rd party needs to reverse engineer it.
- makeitdouble 1y ago
  > "Oops, sorry, didn't get around to documenting it". That's obviously the wrong message. They should say "Go ask the engineering VP to get us off any other projects for another cycle while we're writing 'satisfying' documentation". Extensive documentation comes at a price few companies are willing to pay (and that's not just a matter of resources. Look at Apple's documentation)
  - MathMonkeyMan 1y ago
    I write documentation as I'm writing the code. In my opinion, the code is only as good as its documentation -- they're two parts of the same thing. It's mostly comments at the top of files, and sometimes a markdown file in the same directory. This way, good documentation is priced into my estimate for the project. I don't have a work item "spend a few days documenting." Nope, if I'm doing a foo then that includes documenting a foo at the same time.
    - 1y ago
deleted 1y ago
[deleted]
dist1ll 1y ago
Intel still does it. As far as I can see they're the only player in town that provide open, detailed documentation for their high-speed NICs [0]. You can actually write a driver for their 100Gb cards from scratch using their datasheet. Most other vendors would either (1) ignore you, (2) make you sign an NDA or (3) refer you to their poorly documented Linux/BSD driver. Not sure what the situation is for other hardware like NVMe SSDs. [0] 2750 page datasheet for the e810 Ethernet controller https://www.intel.com/content/www/us/en/content-details/613875/intel-ethernet-controller-e810-datasheet.html https://www.intel.com/content/www/us/en/content-details/6138...
- the-rc 1y ago
  On the other hand, see the complete mess that are the IPU6/7 camera chipsets and their Linux support.
  - XorNot 1y ago
    Good christ this is my current work laptop. It...mostly doesn't work. Plug in a USB camera and it'll just go. Several drivers, userspace utilities and other daemons and sometimes gstreamer works, but does Zoom work? Who knows!
- wtallis 1y ago
  The NVMe spec is freely downloadable and sufficient to write a driver with, if your OS already has PCIe support (which doesn't have open specifications). You don't need any vendor-specific features for ordinary everyday use, so it's a bit of a different situation from NICs. (Also, NVMe was in very large part an Intel creation, though it's maintained by an industry consortium.)
- throwaway2037 1y ago
  Wow... that PDF is 2,750 pages! There must be an army of technical writers behind it. That is an incredible technical achievement. Real question: Why do you think Intel does this? Does it guarantee a very strong foothold into data center NICs? I am sure competitors would argue two different angles: (1) this PDF shares too much info; some should be hidden behind an NDA, (2) it's too hard to write (and maintain) this PDF.
andreww591 1y ago
At least for certain types of OSes, it should be relatively easy to get most of Linux's hardware support by porting LKL (https://github.com/lkl/linux https://github.com/lkl/linux) and adding appropriate hooks to access hardware. Of course, your custom kernel will still have to have some of its own code to support core platform/chipset devices, but LKL should pretty much cover just about all I/O devices (and you also get stuff like disk filesystems and a network stack along with the device drivers). Also, it probably wouldn't work so well for typical monolithic kernels, but it should work decently on something that has user-mode driver support.
- snickerbockers 1y ago
  >but LKL should pretty much cover just about all I/O devices (and you also get stuff like disk filesystems and a network stack along with the device drivers). thus calling into question why you ever bothered writing a new kernel in the first place if you were just going to piggyback Linux's device drivers onto some userspace wrapper thingy. Im not necessarily indoctrinated to the point where I can't conceive of Linux being suboptimal in a way which is so fundamental that it requires no less than a completely new OS from scratch but you're never going to get there off of recycling linux's device drivers because that forces you to design your new OS as a linux clone in which cade you definitely did not need to write an entire new kernel from scratch.
  - andrekandre 1y ago
    > you're never going to get there off of recycling linux's device drivers because that forces you to design your new OS as a linux clone in which cade you definitely did not need to write an entire new kernel from scratch. thats in interesting point, and makes me wonder if some kind of open interface for drivers to write to (and os's could implement) wouldn't be worthwhile? probably it would have to be very general in design, but something along the lines of driverkit or iokit might work?
    - pjmlp 1y ago
      That is how all OSes with binary drivers kind of work. However it goes into the same direction of the previous commenter, device drivers are intertwined with the OS semantics, even on microkernels, so eventually it ends being just something like POSIX.
leoc 1y ago
My hunch is that for nearly anyone who is serious about it these days, the way forward is either to have unusually tight control over the underlying platform, or to include a servant Linux installation with your OS. If Windows is a buggy set of device drivers, then Linux is a free set of buggy device drivers. If you're happy with your OS running as a client of a Linux hypervisor indefinitely then you could go for that; otherwise you'd have to try to gradually move bits of the hardware support into your OS over time—ideally faster than new Linux dependencies arise...
deadbabe 1y ago
Wouldn’t LLMs make it way easier
- mrbungie 1y ago
  Only if you are an expert who wants to use time debugging LLM code rather than coding it yourself. PS: Half-joking, you can write some big portions with LLMs but the point stands.
- underdeserver 1y ago
  I think this is one area where LLMS would be particularly bad at. Opaque code with no documentation across the field.
  - deadbabe 1y ago
    Incredible job security
- baq 1y ago
  LLMs trust the docs. This is a rookie mistake in driver development, especially on prerelease hardware
Joker_vD 1y ago
> Modern hardware is just so complicated it would take a long time to completely document, and even longer to write a driver for. You know, one'd think that having a complex hardware should make writing a driver easier because the hardware is able to take care of itself just fine, and provide a reasonable interface, as opposed to devices of the yore which you had to babysit, wasting your main CPU's time, and doing silly stuff like sending them two identical initialization commands with 30 to 50 microseconds delay between or whatever.
- IshKebab 1y ago
  No, the complexity usually isn't hidden. It's the driver's job to do that. I guess one exception maybe is Nvidia who have sort of hidden the complexity by moving most driver functionality onto software on the card. At least that's how I understood it. Don't quote me on that.
  - Joker_vD 1y ago
    > No, the complexity usually isn't hidden. It's the driver's job to do that. Why not, though? We used to have e.g. glass teletypes with microprocessors (8080/8051) in them that exposed a serial bus with very neat command protocol that we still use nowadays, that could boot up, init and self-test all on their own.
  - saagarjha 1y ago
    Yes, and then you get odd behavior you can't introspect because the card is a black box to you.
  - account42 1y ago
    In some cases it is hidden though. USB has a lot of "generic" device classes where (at least in theory) the OS only needs to deal with a standardized interface and whatever actual hardware is behind it is driven by an embedded controller. It's just that most internal hardware initially only cares only about Windows (or only Linux) so it makes more financial sense to develop a more complex driver than a complex firmware. The equation might change later on but by then you are stuck with the hardware design.
lstodd 1y ago
heh, in mid-2000s all I had were a batch of misbehaving SATA controllers under freebsd, and an (actually quite well-written core of a) linux driver was all I had to work with. Without that, we would have probably just switched hw, because the quite obscure bug was in the ASIC, and debugging that on 2005-6-ish hw is just infeasible.
lelele 1y ago
>> These days, you get a medium-level description and a Linux driver of questionable quality. Then how do devices end up up having drivers for major OSes? It's all guesswork?

tanvach 1y ago

Yeah reverse engineering all the drivers is going to be a huge headache.

markus_zhang 1y ago
Sounds like super fun if I could be paid a bit for it. What is an easy gate task to get into “reverse engineering some drivers for some OS”? Second thought: I don’t even know how to write a driver or a kernel, so I better start from there.
- wmf 1y ago
  Asahi Linux.
- toast0 1y ago
  I don't know how you get paid for it, but if you want to write your own kernel, I'd start with an osdev tutorial. started with this one [1], but this one [2] has a promissing name... and I haven't really looked around. It helps to have a concept to guide you too, but you can certainly make some progress on the basics before you figure out what you really want to do. [1] https://wiki.osdev.org/User:Zesterer/Bare_Bones https://wiki.osdev.org/User:Zesterer/Bare_Bones [2] https://osdev.wiki/wiki/Multiboot1_Bare_Bones https://osdev.wiki/wiki/Multiboot1_Bare_Bones
  - markus_zhang 1y ago
    Thanks. I got all the resources covered. But I don’t have the energy to work on them as a side project any more. Alas! I wasted my younger days and hope you fare better!
    - saagarjha 1y ago
      Unfortunately, you are unlikely to be able to jump into just being paid to write an OS with no experience.
- mastermage 1y ago
  Isn't that what low level does on his YouTube channel teach people to reverse engineer stuff?
  - spauldo 1y ago
    Mostly he seems to try to nail all the items on the "how to grow your YouTube channel" checklists. Clickbait sensationalist titles, exaggerated face on the thumbnail, etc. I have a rule that I don't click on any video where I can't tell the subject by the title, and that eliminated him from my watchlist a while ago. I wish the guy luck on becoming a superstar influencer, since that seems to be his goal, but he can do it without my help.

anikom15 1y ago

It’s entirely laziness.

deleted 1y ago
[deleted]

boredatoms 1y ago

Presumably if you’re meta you could pay the vendors enough to write drivers for any arbitrary OS

rwmj 1y ago
But is that a good use of Meta's money? Compared to making a few patches to Linux to fix any performance problems they find. (And I feel bad saying this since Meta obviously did waste eleventy billion on their ridiculous Second Life recreation project ...)
- b112 1y ago
  I don't like Meta, but there used to be a time where big corp used to spend 30% of its budget on R&D. It's how we got all the toys we have now, R&D labs of big Bell and others. So please don't mock the spend. Big spends fail sometimes, and at least people were paid to do the work.
  - rwmj 1y ago
    It's just that it was so obviously going to fail, because there's no mass market for a product that you have to strap onto your face. You didn't need to spend billions to learn that. If they'd spent the money researching nuclear fusion or space flight or a new way to develop microprocessors, I would be cheering their efforts even if they had failed in the end.
  - crote 1y ago
    The difference is that organisations like Bell Labs and Xerox PARC were primarily tech-first: innovations were the result of very clever and creative people doing blue skies research. The most groundbreaking stuff shocked the world while it was still a hacked-together demo, and similarly the cost of failure was quite low. On the other hand, Meta's experiment is primarily CEO-driven. The outcome is predetermined, changing direction is not possible. Sure, clever engineers get to draw the rest of the owl, but that's not very useful when it turns out that everyone needs a horse instead. They are spending a fortune, but rather than getting 900 crappy ideas to throw away and 100 great ones to pick from for continued development, they are developing 1 technological marvel nobody is interested in.

mbac32768 1y ago

Yeah this. I tried to modify a hobby OS recently so it would process the "soft reboot" button (to speed up being rebooted in GCP) and it was so unbelievably hard to figure out how to support it. I tried following the instructions on the OS Dev Wiki and straight up reading what both Linux and FreeBSD do and still couldn't make progress. Yes. The thing that happens when you tell Windows or Linux to "restart". Gave up on this after spending days on it. The people who develop OSes are cut from a different cloth and are not under the usual economic pressures.

gmueckl 1y ago
I also think that they have access to more helpful resources than people outside the field do, e.g. being able to contact people working on the lower layers to get the missing info. These channels exist in the professional world, but they are hard to access.
sitkack 1y ago
The VMM on GCP has only really been tested with Linux. You are kinda wasting your time, the only way to make it work is to make the hobby OS Linux.
- toast0 1y ago
  > You are kinda wasting your time, the only way to make it work is to make the hobby OS Linux. Not the parent, but of course they're wasting their time... That's the point of a hobby OS. I'm working on a hobby OS, and I have no illusions that it's most likely fewer than 10 people will ever run it, and less than 100 will hear about it, but it lets me explore some interesting (to me) ideas, and forces me to learn a little more about random pieces of computing. If I ran on GCP, I'd want the reboot button to work. That sounds useful. On the topic, I don't see why anyone would want to build a general purpose OS. There's enough already and even with the shrinking of hardware variety, there's a lot of stuff to support to make a general purpose OS work on enough hardware for people to consider using it. You can take Linux or a BSD and hack it up pretty good to explore a lot of OS ideas. Chances are you're going to borrow some of their drivers anyway, and then you'll end up with at least some similarity... may as well start there and save a lot of time. (My hobby OS has a custom kernel and custom drivers, but I only support a bare minimum of devices... (pc) console i/o, one real NIC, and virtio-net... that's all I need; I might add support for more NICs and more consoles later)

b112 1y ago

Modern hardware is just so complicated it would take a long time to completely document, and even longer to write a driver for. That's what's claimed. That's what people say, yet it's just an excuse. I've heard the same sort of excuse people have, after they write a massive codebase, then say "Oops, sorry, didn't get around to documenting it". And no, hardware is not more difficult than software to document. If the system is complex, there's more need to document, just as with a huge codebase. On their end, they have new employees to train up, and they have to manage testing. So any excuse that silicon vendors have to deal with such immense complexity? My violin plays for them.

supermatt 1y ago
> If the system is complex, there's more need to document It’s not first party documentation that’s the problem. The problem is that they don’t share that documentation, so in order to get documentation for an “unsupported” OS a 3rd party needs to reverse engineer it.
makeitdouble 1y ago
> "Oops, sorry, didn't get around to documenting it". That's obviously the wrong message. They should say "Go ask the engineering VP to get us off any other projects for another cycle while we're writing 'satisfying' documentation". Extensive documentation comes at a price few companies are willing to pay (and that's not just a matter of resources. Look at Apple's documentation)
- MathMonkeyMan 1y ago
  I write documentation as I'm writing the code. In my opinion, the code is only as good as its documentation -- they're two parts of the same thing. It's mostly comments at the top of files, and sometimes a markdown file in the same directory. This way, good documentation is priced into my estimate for the project. I don't have a work item "spend a few days documenting." Nope, if I'm doing a foo then that includes documenting a foo at the same time.
  - 1y ago

deleted 1y ago

[deleted]

dist1ll 1y ago

Intel still does it. As far as I can see they're the only player in town that provide open, detailed documentation for their high-speed NICs [0]. You can actually write a driver for their 100Gb cards from scratch using their datasheet. Most other vendors would either (1) ignore you, (2) make you sign an NDA or (3) refer you to their poorly documented Linux/BSD driver. Not sure what the situation is for other hardware like NVMe SSDs. [0] 2750 page datasheet for the e810 Ethernet controller https://www.intel.com/content/www/us/en/content-details/613875/intel-ethernet-controller-e810-datasheet.html https://www.intel.com/content/www/us/en/content-details/6138...

the-rc 1y ago
On the other hand, see the complete mess that are the IPU6/7 camera chipsets and their Linux support.
- XorNot 1y ago
  Good christ this is my current work laptop. It...mostly doesn't work. Plug in a USB camera and it'll just go. Several drivers, userspace utilities and other daemons and sometimes gstreamer works, but does Zoom work? Who knows!
wtallis 1y ago
The NVMe spec is freely downloadable and sufficient to write a driver with, if your OS already has PCIe support (which doesn't have open specifications). You don't need any vendor-specific features for ordinary everyday use, so it's a bit of a different situation from NICs. (Also, NVMe was in very large part an Intel creation, though it's maintained by an industry consortium.)
throwaway2037 1y ago
Wow... that PDF is 2,750 pages! There must be an army of technical writers behind it. That is an incredible technical achievement. Real question: Why do you think Intel does this? Does it guarantee a very strong foothold into data center NICs? I am sure competitors would argue two different angles: (1) this PDF shares too much info; some should be hidden behind an NDA, (2) it's too hard to write (and maintain) this PDF.

andreww591 1y ago

At least for certain types of OSes, it should be relatively easy to get most of Linux's hardware support by porting LKL (https://github.com/lkl/linux https://github.com/lkl/linux) and adding appropriate hooks to access hardware. Of course, your custom kernel will still have to have some of its own code to support core platform/chipset devices, but LKL should pretty much cover just about all I/O devices (and you also get stuff like disk filesystems and a network stack along with the device drivers). Also, it probably wouldn't work so well for typical monolithic kernels, but it should work decently on something that has user-mode driver support.

snickerbockers 1y ago
>but LKL should pretty much cover just about all I/O devices (and you also get stuff like disk filesystems and a network stack along with the device drivers). thus calling into question why you ever bothered writing a new kernel in the first place if you were just going to piggyback Linux's device drivers onto some userspace wrapper thingy. Im not necessarily indoctrinated to the point where I can't conceive of Linux being suboptimal in a way which is so fundamental that it requires no less than a completely new OS from scratch but you're never going to get there off of recycling linux's device drivers because that forces you to design your new OS as a linux clone in which cade you definitely did not need to write an entire new kernel from scratch.
- andrekandre 1y ago
  > you're never going to get there off of recycling linux's device drivers because that forces you to design your new OS as a linux clone in which cade you definitely did not need to write an entire new kernel from scratch. thats in interesting point, and makes me wonder if some kind of open interface for drivers to write to (and os's could implement) wouldn't be worthwhile? probably it would have to be very general in design, but something along the lines of driverkit or iokit might work?
  - pjmlp 1y ago
    That is how all OSes with binary drivers kind of work. However it goes into the same direction of the previous commenter, device drivers are intertwined with the OS semantics, even on microkernels, so eventually it ends being just something like POSIX.

leoc 1y ago

My hunch is that for nearly anyone who is serious about it these days, the way forward is either to have unusually tight control over the underlying platform, or to include a servant Linux installation with your OS. If Windows is a buggy set of device drivers, then Linux is a free set of buggy device drivers. If you're happy with your OS running as a client of a Linux hypervisor indefinitely then you could go for that; otherwise you'd have to try to gradually move bits of the hardware support into your OS over time—ideally faster than new Linux dependencies arise...

deadbabe 1y ago

Wouldn’t LLMs make it way easier

mrbungie 1y ago
Only if you are an expert who wants to use time debugging LLM code rather than coding it yourself. PS: Half-joking, you can write some big portions with LLMs but the point stands.
underdeserver 1y ago
I think this is one area where LLMS would be particularly bad at. Opaque code with no documentation across the field.
- deadbabe 1y ago
  Incredible job security
baq 1y ago
LLMs trust the docs. This is a rookie mistake in driver development, especially on prerelease hardware

Joker_vD 1y ago

> Modern hardware is just so complicated it would take a long time to completely document, and even longer to write a driver for. You know, one'd think that having a complex hardware should make writing a driver easier because the hardware is able to take care of itself just fine, and provide a reasonable interface, as opposed to devices of the yore which you had to babysit, wasting your main CPU's time, and doing silly stuff like sending them two identical initialization commands with 30 to 50 microseconds delay between or whatever.

IshKebab 1y ago
No, the complexity usually isn't hidden. It's the driver's job to do that. I guess one exception maybe is Nvidia who have sort of hidden the complexity by moving most driver functionality onto software on the card. At least that's how I understood it. Don't quote me on that.
- Joker_vD 1y ago
  > No, the complexity usually isn't hidden. It's the driver's job to do that. Why not, though? We used to have e.g. glass teletypes with microprocessors (8080/8051) in them that exposed a serial bus with very neat command protocol that we still use nowadays, that could boot up, init and self-test all on their own.
- saagarjha 1y ago
  Yes, and then you get odd behavior you can't introspect because the card is a black box to you.
- account42 1y ago
  In some cases it is hidden though. USB has a lot of "generic" device classes where (at least in theory) the OS only needs to deal with a standardized interface and whatever actual hardware is behind it is driven by an embedded controller. It's just that most internal hardware initially only cares only about Windows (or only Linux) so it makes more financial sense to develop a more complex driver than a complex firmware. The equation might change later on but by then you are stuck with the hardware design.

lstodd 1y ago

heh, in mid-2000s all I had were a batch of misbehaving SATA controllers under freebsd, and an (actually quite well-written core of a) linux driver was all I had to work with. Without that, we would have probably just switched hw, because the quite obscure bug was in the ASIC, and debugging that on 2005-6-ish hw is just infeasible.

lelele 1y ago

>> These days, you get a medium-level description and a Linux driver of questionable quality. Then how do devices end up up having drivers for major OSes? It's all guesswork?