At a very, very high level, you're exactly correct. The state of RAM is written out to disk, and on restore, it's loaded back into memory, and stuff resumes.
But the devil is very much in the details, and you may not have access to any of the details because the datasheets are NDA'd or just flat out not available to anyone outside the OEMs.
The problem is mostly around hardware state. I've written some sleep patches for Linux on a PineBook Pro (I should finish those and try to upstream them...), and the problem is that on restore, you have to put the hardware exactly as it was when you put it to sleep, or things just don't work. The details of both querying the hardware state, and putting it back, range from "fairly straightforward if inefficient" (copying out device register state on sleep, restoring state on resume - but which of them actually matter?) to "really, really nasty, involving going through the init sequences again, then updating state in the proper order."
Resuming from hibernate is almost the same as a cold boot, except that it's a different shutdown state, so the boot firmware may or may not do things the same as on a cold boot. If you've moved PCI devices around to where you want them instead of where the boot firmware put them, you have to shuffle them back to where you want them - and do this in the correct order, which may or may not be the same as the ordering you did it when the kernel first came up.
If any of this isn't done properly, the system will be in a weird state and things might not work on resume. The patches I wrote for my PBP work fine, unless there's audio playing when the system goes to sleep. Then it still doesn't restore audio state properly and I've not taken the time to dive into the Linux sound system enough to understand why... and this is sleep (suspend to RAM), not hibernate (suspend to disk). Coming up from hibernate, the device state might be entirely different.
Like just about anything with modern computers, a simple idea turns into an absolute minefield of implementation details, and the Linux side of things is hindered because you often simply don't have the datasheets. So now you have to reverse engineer Windows drivers if you want support, or guess that, well, this device is in the same family as that similar device we have a leaked datasheet for from some OEM's FTP site, so maaaaybe it uses the same weird register layout, and... etc.
Thanks for the detail: I take it that hibernation is not a core need for data centers/servers, and therefore the major distros like Red Hat & Ubuntu aren't particularly concerned about dedicating resources to this problem?
It's been a while since I've done anything with data centers, but I can't think of a single reason one would bother with hibernating a datacenter server. Even dynamic VM load stuff (think a cluster of machines supporting 1000 VMs that can migrate, turn machines on and off based on load) just shuts down machines, as far as I know. You might get some benefits from sleep if you need rapid wake (5-10 minutes for a big server booting from power off isn't uncommon), but... eh. I don't know anyone messing with that stuff at scale, for sure.
But the devil is very much in the details, and you may not have access to any of the details because the datasheets are NDA'd or just flat out not available to anyone outside the OEMs.
The problem is mostly around hardware state. I've written some sleep patches for Linux on a PineBook Pro (I should finish those and try to upstream them...), and the problem is that on restore, you have to put the hardware exactly as it was when you put it to sleep, or things just don't work. The details of both querying the hardware state, and putting it back, range from "fairly straightforward if inefficient" (copying out device register state on sleep, restoring state on resume - but which of them actually matter?) to "really, really nasty, involving going through the init sequences again, then updating state in the proper order."
Resuming from hibernate is almost the same as a cold boot, except that it's a different shutdown state, so the boot firmware may or may not do things the same as on a cold boot. If you've moved PCI devices around to where you want them instead of where the boot firmware put them, you have to shuffle them back to where you want them - and do this in the correct order, which may or may not be the same as the ordering you did it when the kernel first came up.
If any of this isn't done properly, the system will be in a weird state and things might not work on resume. The patches I wrote for my PBP work fine, unless there's audio playing when the system goes to sleep. Then it still doesn't restore audio state properly and I've not taken the time to dive into the Linux sound system enough to understand why... and this is sleep (suspend to RAM), not hibernate (suspend to disk). Coming up from hibernate, the device state might be entirely different.
Like just about anything with modern computers, a simple idea turns into an absolute minefield of implementation details, and the Linux side of things is hindered because you often simply don't have the datasheets. So now you have to reverse engineer Windows drivers if you want support, or guess that, well, this device is in the same family as that similar device we have a leaked datasheet for from some OEM's FTP site, so maaaaybe it uses the same weird register layout, and... etc.