Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Jul 1995 17:16:56 -0500 (CDT)
From:      Mike Pritchard <mpp@legarto.minn.net>
To:        terry@cs.weber.edu (Terry Lambert)
Cc:        bde@zeta.org.au, hackers@freebsd.org
Subject:   Re: FS root mount handling discrepancy
Message-ID:  <199507162216.RAA01745@mpp.minn.net>
In-Reply-To: <9507162025.AA14100@cs.weber.edu> from "Terry Lambert" at Jul 16, 95 02:25:31 pm

next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
> > mfs_mountroot() and nfs_mountroot() call inittodr() too.  Volatile and
>                                                             ^^^^^^^^^^^^
> > readonly file systems won't have a useful timestamp to call it with.
> 
> [ ... ]
> 
> > I think it currently must be called even when the timestamp is 0.  It
> > doesn't get called except by mountroot routines.
> 
> Should a volatile or a readonly file system call it with (time_t)0 or
> not call it at all?  I thought "not call it at all".
> 
> If it's supposed to call it with 0, then cd9600_mountroot is currently
> broken (I'll do the fix either way; don't worry about fixing it now)?

Each *_mountroot routine should call inittodr, since that routine
is used to establish the system clock from the real time clock
at boot time.  The argument to inittodr is the value the clock is set 
to if the RTC cannot be read for some reason.  

For a volatile file system like MFS, a value of zero should be used.  
For a read-only file system, zero could be used, but if some kind
of reasonable time stamp can be obtained from the file system,
you could use that so the the system clock doesn't time warp all the
way back to Jan 1 1970 if the RTC is dead, just back to the date found
on the CD.  I don't know anything about ISO 9660 file systems, 
but probably using the timestamp of the root directory on the
CD would be OK.  Either way, inittodr will complain that
the RTC was corrupt to warn the user that the clock is screwed up.

You also mentioned adding a time_t field to the mount structure.
Do we really need that?  The only file system that would have any 
use for it would be the root file system, and the value would only 
be used a total of one time.  It would allow the inittodr calls to 
move out of the *_mountroot routines and into main(), but is it 
really worth it? 


Something else interesting I noticed was the the APM routines call
inittodr to reset the system clock to the RTC after a resume
from a suspend, however they call it with a value of zero.
No big deal, but on the off chance that the RTC somehow died
during that interval, the time would warp back to 1/1/70.
Probably calling it with something like:
	inittodr(time.tv_sec)
would be better, since the clock would just start again from 
its last setting before the suspend.
-- 
Mike Pritchard
mpp@legarto.minn.net
"Go that way.  Really fast.  If something gets in your way, turn"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507162216.RAA01745>