Date: Sat, 15 Jul 95 20:35:51 MDT From: terry@cs.weber.edu (Terry Lambert) To: hackers@freebsd.org Subject: FS root mount handling discrepancy Message-ID: <9507160235.AA08512@cs.weber.edu>
next in thread | raw e-mail | index | archive | help
There is a discrepancy in the xxx_mountroot code between several of the file system types that support root mount. I would like to solicit opinions on how this should be resolved. Currently, the routine inittodr() is called as the last act of the routine ffs_mountroot. The purpose of this call is to (apparently) cause a Sun-style "clock has lost NNN days" message to occur on the system console after a boot after a period of no activity. The discrepancy is that the ffs_mountroot routine is the *only* one of all of the root mount routines that calls this routine to cause the message to appear (both the MFS and CD9660 filesystems support root mounts). What I would like to do: I would like to add a time_t to the struct mount and cause the file system specific mount to fill the value out (or not) based on it's own choice of semantics. The point in doing this is that it's the cleanest way to abstract this behaviour in a more general way and to imply to future file system writes that this field should be filled out. The default value of 0 (mount structures are bzero'ed by the xxx_rootmount and xxx_mount routines when they are allocated) would cause the routine to not be called, so the semantics would not cange for file systems where thelast written time being an arbitrary period in the past is irrelevant. The fact that I'm already adding 1958 bytes to the statfs structure to fix the unmount of file systems with more than 90 characters in the mount point (and thus to the mount structure) is probably relevent here (increasing both fields from the arbitrary MNAMELEN value of "90" to MAXPATHLEN/PATHMAX (1024). 8-). The other option is placing the code in the xxx_mountfs routine (or it's equivalent) for each file system. Not only would this not guarante uniformity of access, it would not address the current root mount issues for MFS and CD9660. NFS would remain broken because it does not implement the same structural call graph for root mounts as other file systems. Obviously, I prefer the first option. Let me know if you have any problems with this, otherwise I will go ahead. Regards, Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9507160235.AA08512>