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.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
