From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 3/5] fs: remove ki_nbytes Date: Mon, 2 Feb 2015 15:26:17 +0100 Message-ID: <20150202142617.GC17447@lst.de> References: <1422381313-24034-1-git-send-email-hch@lst.de> <1422381313-24034-4-git-send-email-hch@lst.de> <20150131060841.GM29656@ZenIV.linux.org.uk> <20150202080729.GC9851@lst.de> <20150202081112.GW29656@ZenIV.linux.org.uk> <20150202081431.GX29656@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Miklos Szeredi , linux-aio@kvack.org, linux-fsdevel@vger.kernel.org To: Al Viro Return-path: Received: from verein.lst.de ([213.95.11.211]:44204 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932263AbbBBO0U (ORCPT ); Mon, 2 Feb 2015 09:26:20 -0500 Content-Disposition: inline In-Reply-To: <20150202081431.GX29656@ZenIV.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Feb 02, 2015 at 08:14:31AM +0000, Al Viro wrote: > 13) two odd drivers/usb/gadget instances. I have conversion for f_fs.c, > but legacy/inode.c (ep_read() et.al.) is trickier. The problem in there > is that writev() on a single-element vector is *not* equivalent to plain > write(). The former treats the wrong-direction endpoint as EINVAL; the > latter does > if (usb_endpoint_xfer_isoc(&data->desc)) { > mutex_unlock(&data->lock); > return -EINVAL; > } > DBG (data->dev, "%s halt\n", data->name); > spin_lock_irq (&data->dev->lock); > if (likely (data->ep != NULL)) > usb_ep_set_halt (data->ep); > spin_unlock_irq (&data->dev->lock); > mutex_unlock(&data->lock); > return -EBADMSG; > instead. IOW, for isochronous endpoints behaviour is the same, but the > rest behaves differently. If not for that, that sucker would convert > to (3) easily; I would bet the behavior difference is a bug, might be worth to Cc the usb folks on this issue. I bet we'd want the more complex behavior for both variants. > 14) ipathfs and qibfs: seriously different semantics for write and writev/AIO > write. As in "different set of commands recognized"; AIO write plays like > writev, whether it's vectored or not (and it's always synchronous). > I've no idea who had come up with that... highly innovative API or why > hadn't they simply added two files (it's all on their virtual filesystem, > so they had full control of layout) rather that multiplexing two different > command sets in such a fashion. > > 15) /dev/snd/pcmC*D*[cp]. Again, different semantics for write and writev, > with the latter wanting nr_seqs equal to the number of channels. AIO > non-vectored write fails unless there's only one channel. Not sure how > ALSA userland uses that thing; AIO side is always synchronous, so it might > be simply never used. FWIW, I'm not sure that write() on a single-channel > one is equivalent to 1-element writev() - silencing-related logics seem to > differ. For these weirdos we can pass down a flag in the kiocb about the source of the I/O. We'll need that flags field for non-blocking buffered reads and per-I/O O_SYNC anyway, and it will be very useful for fixing the races around changing the O_DIRECT flag at run time.