From owner-freebsd-hackers Sun Jul 16 15:17:25 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id PAA11411 for hackers-outgoing; Sun, 16 Jul 1995 15:17:25 -0700 Received: from mpp.minn.net (mpp.Minn.Net [204.157.201.242]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id PAA11390 for ; Sun, 16 Jul 1995 15:17:21 -0700 Received: (from mpp@localhost) by mpp.minn.net (8.6.11/8.6.9) id RAA01745; Sun, 16 Jul 1995 17:16:57 -0500 From: Mike Pritchard Message-Id: <199507162216.RAA01745@mpp.minn.net> Subject: Re: FS root mount handling discrepancy To: terry@cs.weber.edu (Terry Lambert) Date: Sun, 16 Jul 1995 17:16:56 -0500 (CDT) Cc: bde@zeta.org.au, hackers@freebsd.org In-Reply-To: <9507162025.AA14100@cs.weber.edu> from "Terry Lambert" at Jul 16, 95 02:25:31 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2434 Sender: hackers-owner@freebsd.org Precedence: bulk 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"