J. Bruce Fields wrote: > On Fri, Jan 23, 2009 at 09:54:20AM +1100, Greg Banks wrote: > >> J. Bruce Fields wrote: >> >>> On Thu, Jan 22, 2009 at 10:59:49AM -0500, Steve Dickson wrote: >>> >>> >>>> J. Bruce Fields wrote: >>>> >>>> >>>> Interesting.... Store something like a reason code (similar to what they have >>>> in he Kerberos) >>>> >>>> >>> Maybe. >>> >>> >>> >>>> in somewhere in the proc file system? >>>> >>>> >>> But then I don't know how you'd associate it with a particular mount >>> attempt. >>> >>> >>> >>> >> You could do something truly awful like add a new code in the unused >> bits of the errno value returned from mount. It would confuse an >> unmodified userspace, but reporting "Unknown Error" isn't much less >> useful than "I/O Error". >> > > There must be cases where the existing error gives us some information, > but not as much as we'd like, so the "Unknown Error" could be a step > backwards for unmodified userspace. An extra mount option (normally > hidden from the user) could be used to tell the kernel that the > application doing the mount was capable of handling the new error codes. > Ugh. > > > Ugh is right. On further thought, you could use the extra mount option to enable a behaviour where the kernel would format into the mount options buffer a string describing the reasons for the mount failure. If the option weren't present the kernel could emit that same message via printk(). -- Greg Banks, P.Engineer, SGI Australian Software Group. the brightly coloured sporks of revolution. I don't speak for SGI. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
