Re: [PATCH 3/5] fs: remove ki_nbytes

[Christoph Hellwig <hch@lst.de>]

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.