[linux-cifs-client] Re: [PATCH] mount.cifs: make return codes match the return codes for /bin/mount (try #2)

[Jeff Layton]

On Wed, 08 Oct 2008 14:26:07 -0400
Jeff Moyer <jmoyer at redhat.com> wrote:

> Jeff Layton <jlayton at redhat.com> writes:
> 
> > The manpage for /bin/mount specifies that the return code should be a
> > positive integer (actually, it's a bitfield). Clean up the return
> > codes from mount.cifs to make them match the expected return values
> > from /bin/mount. This necessary for proper integration with autofs.
> >
> > This is the second attempt at this patch. The main difference here
> > is that this one uses #define'd constants for the exit codes. I
> > also changed a few places to return EX_SYSERR rather than EX_USAGE
> > since it looked like a more appropriate error.
> >
> > Signed-off-by: Jeff Layton <jlayton at redhat.com>
> 
> Well, I don't like the mixed exit()s and return's, but that was there
> before.  There's also the question of whether you really want to return
> the same error code for all of the below cases:
> 
>         if(mount(dev_name, mountpoint, "cifs", flags, options)) {
>                 case 0:
>                 case ENODEV:
>                 case ENXIO:
>                 default:
> 
> But again, that was already there.  If folks find those things
> palatable, then I'm okay with this.  I guess it's worth noting that I am
> somewhat familiar with the mount code, and I believe this is exactly
> what it expects, since it just returns the exit status of the
> fs-specific mount command in the failure case.
> 
> Acked-by: Jeff Moyer <jmoyer at redhat.com>
> 

Thanks Jeff,

   I've got a new patch that replaces the "return -1" calls with
exit(EX_USAGE) for most of these cases, so we should be able to make
that more consistent. I'll plan to commit that one tomorrow unless
anyone has objections.

For the switch statement, I'd rather hold off on making changes there.
I'm working on some cleanup to the cifs_mount() kernel code now as
well. I'd like to wait until that's closer to complete and then
reevaluate the switch as a whole. There may be other cases we need to
handle, and I'm not convinced that the printf's are currently always
correct for the cases that we have there.

-- 
Jeff Layton <jlayton at redhat.com>