Daniel P. Berrangé <berra...@redhat.com> writes: > 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.
Ok. I'll go write some code then. Thanks for the help!
