Date: Fri, 22 Mar 2013 17:10:12 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Alfred Perlstein <bright@mu.org> Cc: arch@FreeBSD.org Subject: Re: Increase the mount path to MAXPATHLEN? Message-ID: <20130322162905.M953@besplex.bde.org> In-Reply-To: <5149E257.7030906@mu.org> References: <20130319201145.GA19260@ambrisko.com> <20130320211433.F1007@besplex.bde.org> <5149E257.7030906@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 20 Mar 2013, Alfred Perlstein wrote: > On 3/20/13 4:14 AM, Bruce Evans wrote: >> ... >> NetBSD "fixed" this long ago by keeping struct statfs unchanged but >> deprecated, but using _VFS_MNAMELEN = 1024 in struct statvfs. In FreeBSD, >> statvfs() and struct statvfs are just minimal compatibility cruft, with >> no names at all in the struct since names are nonstandard. > > This is the approach I would hope to see happen. Making a separate > syscall/method to return a MAXPATHLEN mount path based on fsid would be very > easy and result in a lot less compat cruft. Not very easy. jilles mentioned getfsstat(2), and perhaps getmntinfo(3). I didn't notice/remember that getfsstat() is a syscall and that there are technical reasons for them. These APIs _are_ easy to use since it is often necessary to iterated over all mounted file systems. They assemble more info than you usually want in a nice structured form. > I think it's time to deprecate retrieval of the mount paths via statfs and > instead use another call as do most other unix-like OSes. Hmm, some other unixes have a lame struct statfs (like FreeBSD struct statvfs). I hate to advertise the nmount(2) mistake, but if it were properly bloated, then it would include returning the mount paths as a small part of returning all the mount options. Its unstructured data is hard to parse and is still missing returning of anything AFAIK (not far) for either the call itself or for a hypothetical associated call (its iov arg is not declared as const, but is not documented to be modified to return anything). Its bloat doesn't include always allocating MAXPATHLEN bytes for names. Instead, all of its strings are free-format, so they are unstructured instead. If it were usable, then getmntinfo() could retrieve the pathnames from it. The difficulty is to convert the pathnames to a structured form so that clients of getmntinfo() don't see much difference. Pathnames are about the easiest options to convert to a structured form, since there is already a place to put part of them. Note than applications mostly don't use getfsstat() directly. df(1) and mount(1) only use getmntinfo() directly. So most things can be fixed without changing syscalls. Brce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130322162905.M953>