From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755364AbbCLO6o (ORCPT ); Thu, 12 Mar 2015 10:58:44 -0400 Received: from senator.holtmann.net ([87.106.208.187]:50433 "EHLO mail.holtmann.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752694AbbCLO6l convert rfc822-to-8bit (ORCPT ); Thu, 12 Mar 2015 10:58:41 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Subject: Re: efivarfs and writev() support From: Marcel Holtmann In-Reply-To: <20150312063437.GK29656@ZenIV.linux.org.uk> Date: Thu, 12 Mar 2015 07:58:35 -0700 Cc: Matt Fleming , Linux Kernel Mailing List , linux-efi@vger.kernel.org, Matthew Garrett , Jeremy Kerr , Matt Fleming Content-Transfer-Encoding: 8BIT Message-Id: References: <33E85F72-FCA0-4DF7-B9E1-46D36244FCA3@holtmann.org> <20150311134226.GB24174@codeblueprint.co.uk> <7F5112DD-6998-47D3-B6B9-5618E14E022A@holtmann.org> <20150312063437.GK29656@ZenIV.linux.org.uk> To: Al Viro X-Mailer: Apple Mail (2.2070.6) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Al, >>>> it seems that efivarfs only supports readv(), but when it comes to >>>> writev(), I am getting an error. Is there any reason to not support >>>> vectored write on this filesystem? Especially with the uint32 header >>>> for each file, I think it would make perfect sense to support it. >>> >>> What error are you seeing? I thought that the vfs fell back to a looped >>> write if the file system doesn't support .write_iter()? >> >> that seems to work for readv(), but not for writev(). >> >>> But yes, we definitely should support writev(). >> >> I just get an EIO error and have not traced this down any further. > > What arguments are you feeding to it? Note that the thing is sensitive to > range boundaries; it's not as if series of write() to it would be equivalent > to single write() from concatenation. And writev() is equivalent to > series of write(). I did something really simple and from my point obvious. I took the uint32 header that every file needs and put that in iov[0] pointer and then the rest in iov[1] pointer. The reason was that I didn't want to copy the actual file content around to just add a uint32 header in front of it. > If you want behaviour a-la UDP sockets (syscall boundaries matter, > boundaries between vector elements do not), we can certainly do that, > but this is different from the current semantics. AFAICS, said > semantics makes little sense, but it's a user-visible change... I do not know about the specific semantics of efivarfs and frankly I have not tried every single combination. However it sounds to me that currently it requires that the whole file content is provided with a single write(). I have no idea if this is true or not. I do not know enough about the internals here. Maybe efivarfs just needs to implemented .write_iter properly to actually support writev() and can not rely on a fallback of multiple write() calls. Regards Marcel