From owner-freebsd-hackers  Sat Jul 15 23:37:12 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.cdrom.com (8.6.10/8.6.6) id XAA07152
          for hackers-outgoing; Sat, 15 Jul 1995 23:37:12 -0700
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34])
          by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id XAA07146
          for <hackers@freebsd.org>; Sat, 15 Jul 1995 23:36:58 -0700
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id QAA17212; Sun, 16 Jul 1995 16:33:55 +1000
Date: Sun, 16 Jul 1995 16:33:55 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199507160633.QAA17212@godzilla.zeta.org.au>
To: hackers@freebsd.org, terry@cs.weber.edu
Subject: Re: FS root mount handling discrepancy
Sender: hackers-owner@freebsd.org
Precedence: bulk

>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 timestamp passed to inittodr() is currently only used if the RTC
is broken.  

>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).

mfs_mountroot() and nfs_mountroot() call inittodr() too.  Volatile and
readonly file systems won't have a useful timestamp to call it with.

>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

This seems reasonable.

>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.

I think it currently must be called even when the timestamp is 0.  It
doesn't get called except by mountroot routines.

Bruce