>What you've really invented is hardware drivers, which have been at home in the OS forever.
Those drivers need to actually communicate with something though, that something is exactly what BMCs are. If the hardware physically providing communication with those systems isn't there, no amount of drivers will help. Additionally, many of those things have to be configured before the OS is loaded and the hardware they control is fully initialized. Not possible inside the OS.
>The problem is they put it everywhere instead of only where people asked for it. You can get away with more on something which is opt in because the people who don't like it can get the one without it. So now it doesn't have to be as secure as the other remote management setups, it has to be as secure as not having remote management.
Yeah, I guess that's an aspect I didn't think of. I can see why people wouldn't be happy running remote management on their consumer hardware, I guess my view is biased by the fact that on systems I frequently work with, having a BMC is a given. My only experience with IME in consumer-level hardware was a neutered version of it where remote access wasn't an option, just some local hardware monitoring/management that seemed mostly useless, but I guess that must've changed.
> Those drivers need to actually communicate with something though, that something is exactly what BMCs are. If the hardware physically providing communication with those systems isn't there, no amount of drivers will help. Additionally, many of those things have to be configured before the OS is loaded and the hardware they control is fully initialized. Not possible inside the OS.
You're going to have a chicken and egg situation at boot. The SATA/SAS HBA needs some code to read the OS with, but in a sense this is just a piece of your OS that has to be installed on the HBA, in the same way as grub has to be installed in the boot partition. Once the OS is running it can load different code into the HBA or replace the code that will run on the next boot.
We can argue about whether to call that sort of code a BMC or not but the more important question is if people can replace it or not, so that people can fix things the manufacturer doesn't.
Those drivers need to actually communicate with something though, that something is exactly what BMCs are. If the hardware physically providing communication with those systems isn't there, no amount of drivers will help. Additionally, many of those things have to be configured before the OS is loaded and the hardware they control is fully initialized. Not possible inside the OS.
>The problem is they put it everywhere instead of only where people asked for it. You can get away with more on something which is opt in because the people who don't like it can get the one without it. So now it doesn't have to be as secure as the other remote management setups, it has to be as secure as not having remote management.
Yeah, I guess that's an aspect I didn't think of. I can see why people wouldn't be happy running remote management on their consumer hardware, I guess my view is biased by the fact that on systems I frequently work with, having a BMC is a given. My only experience with IME in consumer-level hardware was a neutered version of it where remote access wasn't an option, just some local hardware monitoring/management that seemed mostly useless, but I guess that must've changed.