Re: [git pull] new mount API

["Theodore Y. Ts'o" <tytso@mit.edu>]

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