Re: [PATCH 36/38] vfs: Add a sample program for the new mount API [ver #10]

[Theodore Y. Ts'o]

On Mon, Jul 30, 2018 at 12:49:38PM -0700, Matthew Wilcox wrote:
> > That said, people have wanted these kinds of extended error
> > descriptors forever, and the reason we haven't added them is that it
> > generally is more pain than it is necessarily worth. I'm not actually
> > at all convinced that has magically changed with the mount
> > configuration thing.
> 
> I'm not convinced we want to do this either, but if there's anywhere we
> do want to do it then mount seems like one of the few places it might be
> worth doing.  The reasons that a mount failed are many, and it doesn't
> seem like a good idea to introduce a new errno every time a network
> filesystem finds a new failure mode.

We've lived without VMS-style error reporting for a long time, and it
*that* much of a real problem.  Even with network file systems, I
don't think it's been that hard of a problem.

I'd also argue that if there was something super-complicated, the
right way to solve that problem is to push that processing into
userspace --- e.g., if President Trump and President Putin both have
to authenticate to the Nuclear Launch Codes server, then in
mount.pentagonfs, the relevant X.509 certificates would be sent to
server in the userspace process, and if there needs to be complex
error messages reflecting Certificate Revocation List handling, etc.,
mount.pentagonfs can use gettextfs so the program can be localized in
English and Russian.  Once the authentication is completed, then
mount.pentagonfs can pass the file descriptor for the network
connection into fsconfig.

So it might be that we're seriously over-thinking things.  Most of the
really complicated error messages are at connection setup time, and
that can be done in userspace, and then userspace can handle all of
that awful gettext, or VMS-style error messages, or whatever other
horrors the I18N community want to inflict on us.  :-)

	    	 	   	   - Ted