From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-efi@vger.kernel.org, "Kweh,
Hock Leong" <hock.leong.kweh@intel.com>,
LKML <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Peter Jones <pjones@redhat.com>
Subject: Re: [RFC 1/3] sysfs,kernfs: add flush operation
Date: Thu, 30 Apr 2015 07:52:27 -0700 [thread overview]
Message-ID: <1430405547.2167.12.camel@HansenPartnership.com> (raw)
In-Reply-To: <20150430131159.GC17936@kroah.com>
On Thu, 2015-04-30 at 15:11 +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 29, 2015 at 04:09:45PM -0700, James Bottomley wrote:
> > From: James Bottomley <JBottomley@Odin.com>
> >
> > This is necessary to allow sysfs operations to return error in close (we are
> > using close to initiate and return a possible error from a transaction).
> >
> > Signed-off-by: James Bottomley <JBottomley@Odin.com>
>
> Are there any side-affects now that we have a flush() call for binary
> files that the vfs will act differently from not defining one at all?
See answer to Andy, but basically, no, VFS flush is only used to tidy up
before close.
To be honest, it might be nice if fsync *would* issue a transaction
because I think having a multi-transaction API with write/fsync/write is
not such a bad thing. It turns out that fsync and fdatasync do have a
VFS op, but it's ->fsync() not ->flush(), so we have the option to wire
this up if anyone finds a use case.
> if not, no objection to me for this change.
Thanks,
James
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2015-04-30 14:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-29 23:07 [RFC 0/3] Add capsule update using error on close semantics James Bottomley
2015-04-29 23:09 ` [RFC 1/3] sysfs,kernfs: add flush operation James Bottomley
2015-04-30 13:11 ` Greg Kroah-Hartman
2015-04-30 14:52 ` James Bottomley [this message]
2015-04-29 23:10 ` [RFC 2/3] firmware_class: split out transaction helpers James Bottomley
2015-04-30 13:11 ` Greg Kroah-Hartman
2015-04-30 14:39 ` James Bottomley
2015-08-27 14:47 ` Matt Fleming
2015-08-27 16:25 ` James Bottomley
2015-08-27 19:43 ` Matt Fleming
2015-04-29 23:12 ` [RFC 3/3] efi: add capsule update capability via sysfs James Bottomley
2015-04-29 23:25 ` Andy Lutomirski
2015-04-29 23:36 ` James Bottomley
2015-04-29 23:39 ` Andy Lutomirski
2015-04-30 9:30 ` [RFC 0/3] Add capsule update using error on close semantics Kweh, Hock Leong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1430405547.2167.12.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=gregkh@linuxfoundation.org \
--cc=hock.leong.kweh@intel.com \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=pjones@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox