Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 22 Apr 2015 10:45:17 -0700 | Subject | Re: [PATCH v4 2/2] efi: an sysfs interface for user to update efi firmware |
| |
On Wed, Apr 22, 2015 at 10:34 AM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > On Wed, 2015-04-22 at 09:50 -0700, Andy Lutomirski wrote: >> On Apr 21, 2015 9:51 PM, "James Bottomley" >> <James.Bottomley@hansenpartnership.com> wrote: >> > >> > On Tue, 2015-04-21 at 20:24 -0700, Andy Lutomirski wrote: >> > > On Tue, Apr 21, 2015 at 7:20 PM, James Bottomley >> > > <James.Bottomley@hansenpartnership.com> wrote: >> > > > On Tue, 2015-04-21 at 18:58 -0700, Andy Lutomirski wrote: >> > > >> On Tue, Apr 21, 2015 at 6:21 PM, James Bottomley >> > > >> <James.Bottomley@hansenpartnership.com> wrote: >> > > >> > Andy, just on the misc device idea, what about triggering the capsule >> > > >> > update from close()? In theory close returns an error code (not sure if >> > > >> > most tools actually check this, though). That means we can do the write >> > > >> > in chunks but pass it in atomically on the close and cat will work >> > > >> > (provided it checks the return code of close). >> > > >> >> > > >> I thought about this but IIRC cat doesn't check the return value from close. >> > > > >> > > > It does in my copy (coreutils-8.23) : >> > > > >> > > > if (!STREQ (infile, "-") && close (input_desc) < 0) >> > > > { >> > > > error (0, errno, "%s", infile); >> > > > ok = false; >> > > > } >> > > > [...] >> > > > if (have_read_stdin && close (STDIN_FILENO) < 0) >> > > > error (EXIT_FAILURE, errno, _("closing standard input")); >> > > > >> > > >> > > True, but it's stdout that we care about, not stdin :( >> > >> > Gosh you're determined to force me to wade through this source code, >> > aren't you? That's handled in lib/closeout.c: >> > >> > /* Close standard output. On error, issue a diagnostic and _exit >> > with status 'exit_failure'. >> > >> > ... >> > >> > >> > The point is that, admittedly much to my surprise, it all looks to be >> > handled by cat ... so we could proceed to have the transaction completed >> > in close in a misc device (or a sysfs file). >> > >> > Unless there are any other rabbits you'd like to pull out of the hat? >> >> No, maybe it's okay, unless there's an issue where the error would >> only be returned on the close of the last reference of the struct >> file. After all, 'cat foo >/sys/bar' doesn't fully close /sys/bar >> until after cat exits. > > No, cat handles that too. It has an atexit() handler for closing > stdout.
Indeed. Strace tells me that:
$ cat foo >bar
opens bar and then execs cat, so cat has the only reference to bar.
So no more rabbits from me :)
--Andy
| |