On 05/ 5/10 01:47 PM, Tom Haynes wrote:
On 05/ 5/10 02:52 PM, Alan Wright wrote:
On 05/ 5/10 08:08 AM, Tom Haynes wrote:
typedef struct share {
struct share *sh_next;
char *sh_path; /* share path */
char *sh_resource; /* share name */
char *sh_fstype; /* protocol string ("nfs" |
"smb") */
char *sh_opts; /* share property string */
char *sh_descr; /* share description */
size_t sh_size;
} share_t;
sh_fstype is not an appropriate name for the contents.
The contents are a protocol and not a filesystem.
sh_proto?
This is actually an existing structure. see:
uts/common/sharefs/share.h
And the layout botch is my fault. No changes are planned
to the existing Nevada structure.
Alan
Yeah, I'm very familiar with that directory.
I dunno why we didn't fix this issue when we first did sharefs.
My guess is back then we talked in terms of fstypes and not
protocols.
I.e., look at the allowed types to share(1M):
[th199...@aus1500-home sharefs]> more /etc/dfs/fstypes
nfs NFS Utilities
autofs AUTOFS Utilities
cachefs CACHEFS Utilities
smbfs CIFS Utilities
Which brings up the point that share(1M) specifies that
the allowed values in sh_fstype are those defined in
fstypes(4). This also occurs with sharetab(4).
So those would be "nfs" and "smbfs". Not "nfs" and "smb".
smb is correct (this is the server-side protocol service)
but it appears to be missing from sharetab(4), which is an
existing bug because smb appears in sharetab today when
you share a file system over smb. We'll open a CR on that.
smbfs is specific to the smb/client, i.e. smbfs is only used
by clients connecting to shares on a server.
Are we changing the parameters to the share command?
Or actually to the Distributed File System (DFS) Administration
commands?
Or does there already exist means for making this mapping
occur? (Yes, it is coded in sharemgr.)
No commands, utilities or man pages should be harmed by
this case. There should be no externally visible effect.
I find that the intent laid out in the man pages is confusing
with the intent laid out in this case. And while some of the
existing code uses sh_fstype to mean a protocol, some of
it uses it to mean a filesystem type.
We can change the wording in the case to use filesystem
(see also below).
This case makes a change in what goes into sh_fstype and
uses the terminology "protocol" and not "filesystem". But
it also exposes that the input and output to the DFS
commands do not match the documentation.
No change to sh_fstype is being proposed, "smb" is already
supported (just not listed in /etc/dfs/fstypes).
If we want to retain fstypes, we need to change the proto
argument in all of the code to use "smbfs" and not "smb".
See above on smb/smbfs.
If we want to use protocols, we need to update the man
pages to the fact that sharetab(4) and friends are no
longer relying on fstypes(4) to define "fstype" and indeed
we ought to change "fstype" to be "proto" in the
man pages and "sh_fstype" to be "sh_proto" in the
code.
If the consensus is that we should change fstype to proto,
that's fine, but I would like to take that as a separate change
because it has a larger impact than this case, including
documentation impact. The intent here is simply to consolidate
on a single share system call, which only impacts libshare and
the nfs and smb servers.
Alan
_______________________________________________
opensolaris-arc mailing list
[email protected]
