From: Amit Gud <agud@redhat.com>
To: Chakravarthi P <pchakravarthi@novell.com>
Cc: Neil Brown <neilb@suse.de>,
nfs@lists.sourceforge.net, Steve Dickson <SteveD@redhat.com>
Subject: Re: [PATCH 0 / 1] Move NFS mount code from util-linux to nfs-utils - take2
Date: Thu, 15 Jun 2006 23:24:26 -0400 [thread overview]
Message-ID: <4492246A.9000206@redhat.com> (raw)
In-Reply-To: <44918BDD.2C84.006B.0@novell.com>
Chakravarthi P wrote:
> in mount.c :
>
> +void mount_usage()
> +{
> + printf("usage: %s remotetarget dir [-rvVwfnh] [-t version] [-o
> nfsoptions]\n", progname);
> + printf("options:\n\t-r\t\tMount file system readonly\n");
> + printf("\t-v\t\tVerbose\n");
> + printf("\t-V\t\tPrint version\n");
> + printf("\t-w\t\tMount file system read-write\n");
>
> 1. isn't it generally a good practice to have usage message over stderr
> ?
> so the user doesn't miss it. even if he chances to redirect the output
> ...
> just a suggestion.
>
yes, good idea.
> + break;
> + case 't':
> + nfs_mount_vers = (strncmp(optarg, "nfs4", 4)) ?
> 0 : 4;
> + break;
>
> 2. i dont think a -t option makes sense for mount.nfs
> mount.nfs itself says it is a nfs file system
> you can pick up the version from -o nfsvers=4 to cater to nfs
> version
> -t is by legacy meant for specifying the filesystem type.
>
> i also don't see why bind and other options need to be there for
> mount.nfs
>
The mount.nfs, though a subcommand for mount, is meant to be used even
as a standalone binary with the limited functionality. -t option is
there because theres just one binary for the different NFS versions, and
-t is just used as a way to give the filesystem type, just like for
mount there are nfs and nfs4 options for -t.
> +
> +int add_mtab(char *fsname, char *mount_point, char *fstype, int flags,
> char *opts, int freq, int passno)
> +{
>
> 3. felt that there can be just be one function called mtab_update that
> can be kept in
> the common utility source files you had so that both umount and
> mount code can use it.
Yes, I will reorganize this.
> in nfs4mount.c
> +#if defined(VAR_LOCK_DIR)
> +#define DEFAULT_DIR VAR_LOCK_DIR
> +#else
> +#define DEFAULT_DIR "/var/lock/subsys"
> +#endif
> +
> +extern int verbose;
> +
> +char *IDMAPLCK = DEFAULT_DIR "/rpcidmapd";
> +#define idmapd_check() do { \
> + if (access(IDMAPLCK, F_OK)) { \
> + printf(_("Warning: rpc.idmapd appears not to be
> running.\n" \
> + " All uids will be mapped to the nobody
> uid.\n")); \
> + } \
> +} while(0);
> +
> +char *GSSDLCK = DEFAULT_DIR "/rpcgssd";
> +#define gssd_check() do { \
> + if (access(GSSDLCK, F_OK)) { \
> + printf(_("Warning: rpc.gssd appears not to be
> running.\n")); \
> + } \
> +} while(0);
>
>
> 4. very nice thing to do ... warn the user if idmapd and gssd are not
> running.
> But then idmapd on suse doesn't seem to be writing into
> /var/lock/subsys ...
> Is /var/lock/subsys/ the standard way for daemons to show their
> existence. ?
> or is creation of /var/run/<daemon_name> a standard ?
> then idmapd scripts might need some change .. or else ..
> code needs some modification here to be able to work fine in all
> distros ...
I suppose /var/lock/subsys/ is the standard directory. I inherited the
DEFAULT_DIR, that was being used in the util-linux mount.
> in nfsumount.c :
>
> + spec = argv[1];
> +
> + argv += 1;
> + argc -= 1;
> +
> + while ((c = getopt_long (argc, argv, "fvnrlh",
> + umount_longopts, NULL)) != -1) {
>
> it'll be nice if you include -a option and have all nfs or nfs4 mounts
> umounted on calling
> umount.nfs -a
> this is should be easy enough with an appropriate mtab utility
> function.
>
Yes, nice idea.
Best,
AG
--
May the source be with you.
http://www.cis.ksu.edu/~gud
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2006-06-16 3:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-12 23:02 [PATCH 0 / 1] Move NFS mount code from util-linux to nfs-utils - take2 Amit Gud
2006-06-15 11:10 ` Chakravarthi P
2006-06-15 17:41 ` Frank Filz
2006-06-15 18:10 ` Chuck Lever
2006-06-16 3:24 ` Amit Gud [this message]
2006-06-16 3:30 ` Neil Brown
2006-06-16 3:45 ` Amit Gud
2006-06-16 3:50 ` Neil Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4492246A.9000206@redhat.com \
--to=agud@redhat.com \
--cc=SteveD@redhat.com \
--cc=neilb@suse.de \
--cc=nfs@lists.sourceforge.net \
--cc=pchakravarthi@novell.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox