4 ms·

> I don't really know what "battery management" means I assume he means "power management" (i.e. ACPI on x86). You can run the system without taking control of

> I don't really know what "battery management" means I assume he means "power management" (i.e. ACPI on x86). You can run the system without taking control of the ACPI hardware, but this is a terrible idea. It'll affect your ability to run the CPU properly, even assuming you don't care about power usage (and large server deployments sure do!). Not to mention all the nasty bugs and problems you'll run into because the hardware wasn't designed to run for long periods of time without ACPI active.

asadjb 10y ago
But would that matter, given more and more of our machines are running on a hypervisor of some sort? I know it's almost mandatory for the base machine running on actual hardware, but given that most of the servers we use now are just virtualized, how bad would removing ACPI support be? Also, would it be useful to remove that?
- kijin 10y ago
  Something needs to run on actual hardware. There are benefits to using the same components both inside and outside of the VM, just as there are benefits to using the same codebase bother on the server side and on the client side. There's less code to maintain, and you don't have to spend time worrying about compatibility. I wouldn't mind the small inefficiency of carrying extra drivers and subsystems inside of my VM if it helps make my stack as a whole more uniform and predictable. We really don't need yet another Linux distribution.
- johncolanduoni 10y ago
  Not really. You'd have to come up with your own standard for conveying configuration information and shutdown/restart at least (for this thin guest I'm guessing you wouldn't mind losing suspend). I believe you'd also lose memory hotplug (although I don't think you'd lose memory ballooning) unless you implemented that too. That's a new standard, and new code for your guest and hypervisor. Also I remember reading something about some hypervisors using the guest's decisions with regards to CPU power states to inform the hypervisor's setting of the same on the real hardware. I'm not sure if this is implemented in mainstream hypervisors, or if it's really useful, but that's another thing you'd lose.

asadjb 10y ago

But would that matter, given more and more of our machines are running on a hypervisor of some sort? I know it's almost mandatory for the base machine running on actual hardware, but given that most of the servers we use now are just virtualized, how bad would removing ACPI support be? Also, would it be useful to remove that?

kijin 10y ago
Something needs to run on actual hardware. There are benefits to using the same components both inside and outside of the VM, just as there are benefits to using the same codebase bother on the server side and on the client side. There's less code to maintain, and you don't have to spend time worrying about compatibility. I wouldn't mind the small inefficiency of carrying extra drivers and subsystems inside of my VM if it helps make my stack as a whole more uniform and predictable. We really don't need yet another Linux distribution.
johncolanduoni 10y ago
Not really. You'd have to come up with your own standard for conveying configuration information and shutdown/restart at least (for this thin guest I'm guessing you wouldn't mind losing suspend). I believe you'd also lose memory hotplug (although I don't think you'd lose memory ballooning) unless you implemented that too. That's a new standard, and new code for your guest and hypervisor. Also I remember reading something about some hypervisors using the guest's decisions with regards to CPU power states to inform the hypervisor's setting of the same on the real hardware. I'm not sure if this is implemented in mainstream hypervisors, or if it's really useful, but that's another thing you'd lose.