[Note: this got scheduled because I suggested it as a topic on the application form. I'm still not convinced it's that relevant and it could become a lightning talk instead if there's not much interest] This came up as a problem because efivarfs needs a hibernate hook. The specific efivarfs problem is that when the kernel is running, it owns the EFI runtime interface, so nothing can update variables without going through the kernel and so the cache of efivarfs (held in the variable dentries) reflects exactly the state of the underlying variables. However, when the system is hibernated, other OSs could boot and alter EFI variables, so the exact cache correspondence guarantee is broken and efivarfs needs to resync the variable store on resume from hibernate. Part of the thought here is that other filesystems might possibly want suspend resume hooks as well, although not for the reasons efivarfs does: Hibernate is a particularly risky operation and resume may not work leading to a full reboot and filesystem inconsistencies. In many ways, a failed resume is exactly like a system crash, for which filesystems already make specific guarantees. However, it is a crash for which they could, if they had power management hooks, be forewarned and possibly make the filesystem cleaner for eventual full restore. Things like guaranteeing that uncommitted data would be preserved even if a resume failed, which isn't something we guarantee across a crash today. The other reason for discussing this is that adding power management hooks directly to efivarfs resulted in a lot of deadlock potential (discussion of which is already on linux-fsdevel), which could potentially be lessened by making it part of the VFS API. If other filesystems think they might use it in future, we should discuss how this could work. Regards, James
