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
