| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Sun, 21 Nov 2010 13:14:53 -0800 (PST) From: David Miller <davem@...emloft.net> To: tony.luck@...el.com Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org, tglx@...utronix.de, mingo@...e.hu, greg@...ah.com, akpm@...ux-foundation.org, ying.huang@...el.com Subject: Re: [RFC] persistent store From: "Luck, Tony" <tony.luck@...el.com> Date: Sat, 20 Nov 2010 15:48:19 -0800 > The usage model I'm envisioning is that a platform driver > will register with this code to provide the actual storage. > I've tried to make this interface general, but I'm working > from a sample of one (the ACPI ERST code), so if anyone else > has some persistent store that can't be handled by this code, > speak up and we can put in the necessary tweaks. > > My assumptions are that the data that Linux cares about will > be wrapped in some error record structure with a header, and > possibly a footer that the device code needs. So the driver > specifies how much padding to put around a buffer to make > life easy for it. It also specifies the maximum number of > bytes that can be saved in one record. Thanks for doing this work Tony. On sparc64 I can mark an arbitrary region of physical memory as persistent across soft reboots. So I'll likely use that to implement these interfaces. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists