> After tracing down the sys_mount, do_mount and read_super....
> I found that in nfs client, server ip address is transfered to
> nfs_read_super() in nfs/inode.c as a argument "void *data",
> which I believe from
> sys_mount( ... , void * data )
>
> but in my fs client, the "data" is a null pointer, that's where the
> error from. I am not sure how nfs client can get the data value.
> Is there any special operation for nfs in calling sys_mount from
> mount system call?
The problem isn't in the mount system call; it's in the user-level
mount utility. mount has special-case code for NFS; when you call
'mount -t nfs foo:/bar /baz', the mount utility makes an NFS mount RPC
from userlevel, packs the results into an nfs_mount_data structure,
and passes that structure to the mount syscall.
Since your filesystem has a different ID than nfs, the mount utility
doesn't know what to do with it, so it treats it like a normal on-disk
filesystem that doesn't need special mount data, which is why you get
a NULL data pointer in your nfs_read_super.
There are two solutions to this:
1. You can hack /sbin/mount and either insert additional special-case
code to handle your filesystem or enable the "always check for the
existence of an /sbin/mount.<fsid> where <fsid> is the filesystem
type" option. I use the latter in my filesystem work; it just requires
me to drop a mount.edrfs binary in /sbin when testing things. If you
use the mount helper approach, your helper will need to both perform
the mount and mangle /etc/mtab appropriately. If you add your code to
mount itself, you may be able to get more code reuse. I can't say for
sure, though, since I avoided that route (it's less generic, and I
wanted to GPL-contaminate as little of my code as possible).
If you like, I can give you either a patch to mount or a source RPM
with the required changes to enable helper programs.
2. You can write your own mount program and call that to mount the
filesystem instead of "mount". Netware uses this approach with its
ncpmount utility. This is probably easier, but somewhat more
inconvenient for users.
(Ideally, I'd just be able to say "here, I did it this way, look at my
code", but our tech transfer office won't give us a license so we can
release it. goddamn lawyers.)
--nat
-- nat lanza --------------------- research programmer, parallel data lab, cmu scs magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/