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.
--b.
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.