On Apr 21, 2015 9:51 PM, "James Bottomley"
<james.bottom...@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.bottom...@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.bottom...@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.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
