On Tue, Mar 10, 2015 at 8:40 AM, Peter Jones <pjones@xxxxxxxxxx> wrote: > >> >> So, for the sysfs interface, let's not allow loading from /lib. Let's >> >> not require a userland tool. Let's just do, >> >> >> >> # echo /path/to/my/awesome/capsule.bin > /sys/../capsule >> > >> >> >> >> and be done with it. >> >> >> >> Hmmm? >> > >> > I assume you're implying a) the capsule header with the guid is embedded >> > in the .bin there already, and b) one contiguous write(2) with error >> > reporting coming through something like vars.c's efi_status_to_err()? >> > >> > If so, yes, I prefer this API. >> > >> >> Is using a char device really so bad? I have a "simple_char" that >> makes this really easy that's pending review. > > As long as there's straightforward propagation of the EFI_STATUS return > from UpdateCapsule() back, sysfs file vs char device makes very little > difference to me. Either way it's open(), write(), close(). Using the > runtime firmware upload interface designed for wifi and scsi devices is > the part I don't really like. > I'm not 100% happy with write(2) (which is all we have in sysfs) for two reasons: 1. If we write a file name, eww. That's more complicated, requires temporary files, has annoying mount namespace issues, etc. 2. If we write the full contents, we need to do it in a single call to write. That means that we can't use cat, which mostly defeats the purpose. In fact, using cat could be actively harmful. --Andy -- 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
