Date: Mon, 14 Feb 2011 08:33:37 +0200 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Garrett Cooper <yanegomi@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: The history behind the undocumented NetBSD stat syscalls? Message-ID: <20110214063337.GB4241@tops> In-Reply-To: <AANLkTiniX4xe8ri2CYFn34AMyeC4m0eR4WJv8-b4SXkN@mail.gmail.com> References: <AANLkTiniX4xe8ri2CYFn34AMyeC4m0eR4WJv8-b4SXkN@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On (13/02/2011 13:39), Garrett Cooper wrote:
> Hi FS folks,
> I was poking through vfs_syscalls.c and I noticed that there was a
> syscall called nlstat, and nstat, and a kernel-public only helper
> function called cvtnstat:
> These aren't used anywhere in our source tree (I trimmed out the
> false positives -- i.e. connstat and instat), minus their declarations
> in kern/vfs_syscalls.c, etc:
>
> $ svngrep -Er 'nl?stat\(' /usr/src/
> /usr/src/sys/kern/kern_descrip.c: cvtnstat(&ub, &nub);
> /usr/src/sys/kern/syscalls.master:278 AUE_STAT STD { int nstat(char
> *path, struct nstat *ub); }
> /usr/src/sys/kern/syscalls.master:280 AUE_LSTAT STD { int nlstat(char
> *path, struct nstat *ub); }
> /usr/src/sys/kern/vfs_syscalls.c:cvtnstat(sb, nsb)
> /usr/src/sys/kern/vfs_syscalls.c:nstat(td, uap)
> /usr/src/sys/kern/vfs_syscalls.c: cvtnstat(&sb, &nsb);
> /usr/src/sys/kern/vfs_syscalls.c:nlstat(td, uap)
> /usr/src/sys/kern/vfs_syscalls.c: cvtnstat(&sb, &nsb);
> /usr/src/sys/compat/freebsd32/syscalls.master:278 AUE_STAT NOPROTO{
> int nstat(char *path, struct nstat *ub); }
> /usr/src/sys/compat/freebsd32/syscalls.master:280 AUE_LSTAT NOPROTO{
> int nlstat(char *path, struct nstat *ub); }
> /usr/src/sys/sys/vnode.h:void cvtnstat(struct stat *sb, struct nstat *nsb);
> /usr/src/sys/sys/sysproto.h:int nstat(struct thread *, struct nstat_args *);
> /usr/src/sys/sys/sysproto.h:int nlstat(struct thread *, struct nlstat_args *);
>
> And seems like it should be superseded by lstat, et all, which
> were introduced a little earlier on [1].
> Do they serve a real purpose of some kind today? It was introduced
> in the revision seen in SVN here [2], and looking back in time there
> isn't reference to a NetBSD compat layer in sys/conf/options [3], etc,
> so I was a bit curious why there are dangling undocumented (but
> publicly visible via sysproto.h) VFS-related syscalls entries hanging
> around (in particular because the syscalls aren't declared that way in
> NetBSD either).
These were dropped by Dragonfly as not being used. NetBSD is no longer
compatible with them, afair.
freebsd32 compatibility shims are incorrect, which means that nobody
ever used them.
If you are interested, I have a patch marking them COMPAT8 and OBSOL for
freebsd32, it's part of larger set of changes to make ino_t 64 bit:
https://github.com/downloads/glk/freebsd-ino64/freebsd-ino64-patch-2011-01-20.tgz
> Thanks!
> -Garrett
>
> 1. http://svn.freebsd.org/viewvc/base/head/sys/kern/vfs_syscalls.c?revision=24438&view=markup
> 2. http://svn.freebsd.org/viewvc/base/head/sys/kern/vfs_syscalls.c?revision=35938&view=markup
> 3. http://svn.freebsd.org/viewvc/base/head/sys/conf/options?view=log
> _______________________________________________
> freebsd-fs@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110214063337.GB4241>