Implementing Suspend to Ram

Development OS
1

Hello Everyone,
I am poking a bit into the Haiku Kernel source Code, to see if it is feasable for me to implement Suspend to Ram.

I know it’s a complex effort, so for now I have looked at the existing code for acpi and shutdown.

It looks like there is enough Acpi support to define a wakeup vector, so this is what I want to try.

However, for the wakeup vector I need to allocate a specific area of memory some time early in the bootup.

So here are my questions:

  1. What is the API to use inside Haiku Kernel to reserve memory in a specific range?
  2. What Code is run during early startup that I could hook into to run the allocation?

Thanks :slight_smile:

13 Likes
2

Did you check on Trac if there are tickets about the subject? You may find an enhancement request with hints about what needs to be done in comments.

1 Like
3

There is not much in the ticket system about it:

1 Like
4

You probably should read the whole KernelKit to try and find something for your 1st question. for the 2nd question, one of devs will have a more precise explanation, so you"ll have to wait until they see your post.

4 Likes
5

There is some sleep on idle implemented, you can read on the first implementation here: cpuidle: GSoC community bonding report | Haiku Project

It was later changed when kernel scheduler was reworked. However nobody even looked at suspending to ram afaik know.
I’m guessing sleeping and waking drivers will be a problem, but I have no idea.

There is also a lid driver but not sure what it does or if it is in the Haiku image. Most of the ACPI related drivers is under the power directory: haiku/src/add-ons/kernel/drivers/power at master · haiku/haiku · GitHub

And you probably want to use create_area, as documented in the old BeBook docs (not sure why I cannot find Kernel Kit docs Haiku Book): The Be Book - Classes And Methods - The Kernel Kit

2 Likes
6

Regarding drivers: a minimal interface was already defined, that consist of “suspend” and “resume” calls in the drivers. But no dri_ers implement them and nothing in the kernel calls them. So that needs to be filled in.

One problem is suspending and resuming things in the correct order. Dependencies between drivers may not always be obvious.

The other thing, of course,is implementing the suspend/resume in each driver. And there is a decent number of drivers, so that will be some work.

2 Likes
8

Thanks for your effort - I like this feature generally and used to use it if available …

1 Like