On Wed, Jun 7, 2017 at 7:36 PM, Hiltjo Posthuma <hil...@codemadness.org> wrote:
> On Wed, Jun 07, 2017 at 08:32:26AM +0200, Silvan Jegen wrote:
>> On Tue, Jun 6, 2017 at 8:55 PM, Rendov Norra <tsobf...@gmail.com> wrote:
>> > Reading the source code, it seems that error represents any failure
>> > from mount(). It seems overlayfs wasn't compiled with my kernel.
>>
>> Having better error handling that either takes into account all of the
>> errors returned by mount (2) or passes them on would be nice.
>>
>> In your case the mount call most likely returned:
>>
>> "ENODEV filesystemtype not configured in the kernel."
>>
>> (from mount (2))
>>
>
> This can be filesystem-specific. Mount just returns the errstr at the
> moment.
>
> Feel free to send a patch with your idea however.
*Obviously* I was hoping someone else would do the work :P
I had a look at the implementation and it looks to me like we could do
it in two ways:
1. Use a switch statement on errno and print a string version of the
error description in the mount (2) man page. This would be convenient
for the user (because he just gets the possible errors listed on the
command line) but it wouldn't be general.
2. Write some helper function to map the errno numbers to the symbolic
error names (i. e. EAGAIN, EACCES, etc.). There is no stdlib
functionality for this so we would have to do it ourselves. The
advantage of this would be that we could use this helper function
throughout {s,u}base. The disadvantage (other than that we would have
to write more code) is that the user would just get the symbolic name
and then would have to look it up him/herself in the manpage.
Some errnos are mapped to several errors but there is not much we can
do about that.
I prefer the second approach. Thoughts?
Cheers,
Silvan
