On Thu, Aug 23, 2018 at 09:51:00PM -0700, Andy Lutomirski wrote: > When this was reviewed earlier, a problem was identified. I asked if > it had been addressed. I did *not* say that it was mandatory to > address it, nor did I say anything about reworking fs drivers. > > A reasonable answer might have been "avoiding this pitfall in the new > API would involve a large amount of reworking of existing filesystem > drivers. I think that the new API, as is, has enough benefits that it > makes sense to merge it even with this pitfall, and, if needed, we can > introduce an improved version down the road." It's also not clear that an API that you think is "cleaner" would actually be more usable. In fact, I believe it's going to be a sh*t show for userspace, because it won't be obvious what will work, and what will cause an error of the form, "sorry we can't do this cleaner thing that some people think is better". Which means a huge amount of special casing in the program, or a lot of very surprising failures that will then get exposed to the system administrator, many of whom haven't really had much of a problem with the existing mount(8) user interface. It may very well be that the "cleaner" approach will be hellacious from a human usability perspective. Figuring all of this out could take months and months (stalling the new mount API for a long time), and we may never know for sure until we implement a full prototype of kernel changes, massive rewrite of the file systems, and userspace programs --- and then see what is the best way to expose the radically different semantics depending on what individual file systems can and can not do to the poor human system administrator who is just trying to mount the d*mned file system. - Ted
