On Mon, Aug 10, 2015 at 03:02:22PM -0400, Gabriel L. Somlo wrote:

Mainly, qemu's fw_cfg is a read-only "device", so one wouldn't ever care to try writing anything to it. /sys/firmware/... feels like a fit because fw_cfg contains binary blobs originally meant to be used by the bios (it's how SeaBIOS and OVMF pull smbios and acpi tables out of the host and set them up in guest memory before booting the guest kernel, as one of the many examples).

The most similar example (and the existing driver I used as an example during implementation) is dmi-sysfs.c, which also exposes all the metadata for each smbios table as numeric (or string) read-only attributes, and has a "raw" attribute which allows dumping each table in its entirety. Same thing here -- I want to expose the name, size, and select key for each blob, but also allow access to the "payload", i.e. the blob itself.

That's great, and you can have these "blobs" be an attribute for a struct device. Just using a "raw" kobject as you are is hard, as you have seen, and messy. Making it a "real" device makes this all much easier and simpler. Now if you want to keep things in /sys/firmware/ that's another issue, and would have to stay as a kobject. so maybe it does need to remain, need to think about that... thanks, greg k-h