On Tue, 14 Apr, at 06:18:33PM, Borislav Petkov wrote: > On Tue, Apr 14, 2015 at 11:56:26AM -0400, Andy Lutomirski wrote: > > This is why I think that the right approach would be to avoid using > > firmware_class entirely for this. IMO a simple_char device would be > > the way to go (hint hint...) but other simple approaches are certainly > > possible. > > Btw, didn't mfleming want to try using capsules for other funky stuff > like early logging and pstore-like logging in panic time so that we can > read out crash data on the next boot? Yeah, exactly. Being able to pass random data blobs to the capsule internals allows the kernel to support cool things we haven't conceived of yet, and where we want to use the capsule's in-memory persistence across reboot to pass data to the next kernel. The panic code paths is just one example. > Which would mean that capsules would need a completely different > interface, something new for shuffling lotsa binary data in and out of > the kernel and in and out of the UEFI... > > Which would make the firmware_class thing completely inappropriate for > that. Well, I haven't come across a scenario where you need a brand new interface for getting it *out* of the kernel again. And I'm happy enough with these patches for passing data in. -- Matt Fleming, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
