On Wed, Oct 02, 2019 at 04:35:55PM -0400, Jeff Layton wrote: > On Wed, 2019-10-02 at 15:27 -0400, J. Bruce Fields wrote: > > On Wed, Oct 02, 2019 at 08:28:40AM -0400, Jeff Layton wrote: > > > For the byte ranges, the catch there is that extending the userland > > > interface for that later will be difficult. > > > > Why would it be difficult? > > Legacy userland code that wanted to use byte range enabled layouts would > have to be rebuilt to take advantage of them. If we require a range from > the get-go, then they will get the benefit of them once they're > available. I can't see writing byte-range code for a kernel that doesn't support that yet. How would I test it? > > > What I'd probably suggest > > > (and what would jive with the way pNFS works) would be to go ahead and > > > add an offset and length to the arguments and result (maybe also > > > whence?). > > > > Why not add new commands with range arguments later if it turns out to > > be necessary? > > We could do that. It'd be a little ugly, IMO, simply because then we'd > end up with two interfaces that do almost the exact same thing. > > Should byte-range layouts at that point conflict with non-byte range > layouts, or should they be in different "spaces" (a'la POSIX and flock > locks)? When it's all one interface, those sorts of questions sort of > answer themselves. When they aren't we'll have to document them clearly > and I think the result will be more confusing for userland programmers. I was hoping they'd be in the same space, with the old interface just defined to deal in locks with range [0,∞). I'm just worried about getting the interface wrong if it's specified without being implemented. Maybe this is straightforward enough that there's not a risk, I don't know. --b.
