On Apr 21, 2015 9:51 PM, "James Bottomley"
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx> 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.
--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
