On Wed, Nov 01, 2023 at 09:16:33AM -0300, Fabiano Rosas wrote: > Daniel P. Berrangé <berra...@redhat.com> writes: > > > > > So the problem with add-fd is that when requesting a FD, the monitor > > code masks flags with O_ACCMODE. What if we extended it such that > > the monitor masked with O_ACCMODE | O_DIRECT. > > > > That would let us pass 1 plain FD and one O_DIRECT fd, and be able > > to ask for each separately by setting O_DIRECT or not. > > That would likely work. The usage gets a little more complicated, but > we'd be using fdset as it was intended. > > Should we keep the direct-io capability? If the user now needs to set > O_DIRECT and also set the cap, that seems a little redundant. I could > keep O_DIRECT in the flags (when supported) and test after open if we > got the flag set. If it's not set, then we remove O_DIRECT from the > flags and retry.
While it is redundant, I like the idea of always requireing the direct-io capabilty to be set, as a statement of intent. There's a decent chance for apps to mess up with FD passing, and so by seeing the 'direct-io' capability we know what the app intended todo. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
