Date: Sun, 16 Jul 95 17:25:21 MDT From: terry@cs.weber.edu (Terry Lambert) To: mpp@legarto.minn.net (Mike Pritchard) Cc: bde@zeta.org.au, hackers@freebsd.org Subject: Re: FS root mount handling discrepancy Message-ID: <9507162325.AA17210@cs.weber.edu> In-Reply-To: <199507162216.RAA01745@mpp.minn.net> from "Mike Pritchard" at Jul 16, 95 05:16:56 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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? I believe the answer is "yes", and here's why: The intent of the time_t addition to the mount structure is to provide a mechanism to communicate a file system specific time stamp to the inittdr() call in a system independent way. This is desirable because currently, the per FS XXX_vfsops structure contains support code for a "generic" mount and a "root" mount. The generic mount is the exported interface is is not adequate for use for a root mount. The result of this is that there is kernel specific promiscuous knowledge of the file system types external routines in the root mount call code; specifically, there are file system specific root mount attempts for all supported file systems with root mount capability based on the boot device specified to the kernel. I believe this to be inherently bogus. Specifically, it is possible to provide a file system type such that standard mounts or root mounts and not both are a possibility. This is a violation of the abstraction architecture specified by John Heidemann in the design: basically, pounding the design to fit into BSD. My intent is to modify the file system specific mount routine to be callable either from the vfs_calls.c mount routine OR from a system specific mount routine. Architecturally, this boils down to the following sequence of changes: o Add an arguments structure to the ffs_mountfs, similar to the existing one in the cd9660 file system. The purpose of this argument structure is to allow the passing of arguments indicating a root or non-root mount is to take place. o Move the ffs_mountfs into the place currently held by the ffs_mount routine. o Move the file system independent mount housekeeping into the mount system call or the vfs_mountroot (new procedure). o Move the file system dependent mount housekeeping (like the storage of the device and "last mounted on" names) below the interface layer where they belong. This is the initial mount code cleanup necessary to abstract the file system depence on the BSD file system mount heirarchy paradigm that is not intrinsic to the file system code itself. This is also the second rationale (that I promised) for an MFS specific mfs_mountfs: to handle the MFS specific code in the mfs_mountroot and mfs_mount in the mfs_mountfs routine instead. Once this is complete, the interface changes will allow a file system to refuse root mount based on the fact that the file system itself is not root capable rather than based on the arbitrary existance of code hacks to the system initialization routines. One consequence of this is the ability to boot using an embedded file system type (statically inked into the kernel), load another file system type dynamically, and subsequently mount root with the loaded file system. The utility of this mechanism as a means of booting to an existing file system type not the default for BSD (for instance, the OSF/1 UFS implementation on DEC Alpha hardware) should be obvious. A second consequence of these changes is the ability of the file system writer to easily and obviously support the concept of root file system mounts as well as direct file system mounts. The intent here is to support, among outher thing, EXT2FS, UMSDOSFS, and LFS root file system types. This means a mount operation returns a locked pointer to an allocated mount structure in the final version of the interface; the mount houskeeping on vnode coverage, etc. is moved out of the file system itself: it loses the need for knowledge of BSD internals. This means that developers are free to work on issues requiring changes to those internals. One specific example is that of nomadic computing and ambiguous network connectivity. Subsequent changes to the mount interface are also planned: o Move the file system specific mount knowledge (with the exception of the ":" being used for remote file system identification) OUT of the mount command and into per file system code (still hidden under the mount command). This finally resolves the ability to drop in file systems at the administrator level as modules without requiring a kernel rebuild (only a module load). o Change the per file system instace structure to include a named identifier for the file system. o Change the semantics of the mount command to use the named identifier (passing it down) instead of the manifest constants it currently uses. This resolves the biggest block to adding in unpredected file system types without a need to change system header file (the enumerated types in sys/mount.h) or rebuild the system kernel. Some support code is probably necessary: o A mechanism for iterating the supported file system types currently in the kenel. Later, it is probably desirable to seperate this information out, either with direct file system support of an fstyp-style interface (and seperate the probe and the rest of the file system code into two loadable modules), or by using a user space directory iteration an a manifest constant path for file system utilities that *must* exist to iterate types. Since this bears on the ability to build user space utilties that globally manage all file system types without explicit knowledge of what file system types exist on the machine (like a smit-like mount utility), the support code can wait until someone wants to tackle the utility. Finally, taken together, these provide several services relevant to plug-n-play, most notably the ability to, when new media is detected, iterate the file system types in the kernel and "ask" if each FS "wants" the media. For immediate use, we have removable media, such as floppies, zip disks, "formatted" PCMCIA cards, and CDROMs -- all of which could benefit from auto-recognition of file system from the media. > 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. I'd have to say that that APM code was probably broken. One of the fundamental assumptions that needs to be made when spanning a suspend operation is that there will be a record of the period of the suspend. I'd have to say that calling it with 0 was incorrect. Potentially, calling it at all (in the expectation that the RTC is incorrect) is probably a bad idea, and an alternate interface should be presented. One suggestion may be to adopt the PReP recommendations in this area: 4.4.8 Calendar and Timer Services These run-time abstractions provide services for the various clocks and calendars within the system. They must account for the non-volatile Real-Time Clock in the system, the 601 [sic] processor RTC, the Time Base on other PowerPC [sic] processors, the decrementer which provides n interrupt after counting down to zero, and the ability to change clock frequency supplied on some PowerPC [sic] processors. ... 4.4.10 Power Management If macro power management is supported by the operating system, then the abstraction layer must provide a means to change the device and subsystem power states. It must also provide a means to read and write system information. In this last, I thinkthe current processor RTC value qualifies as "system information". If someone wants to seriously hack on that code, I suggest: _Plug and Play for PowerPC Reference Platform_ Gary Tsao An IBM white paper Contact IBM @ 1-512-838-5552 and _Microsoft Hardware Abstraction Layer_ Beta Version March 1993 Microsoft, Inc. You might be able to pry this last out of MS at: The Windows NT Porting Center IBM, Inc. Contact @ 1-800-803-0110 or 1-206-889-9011 or winntppc@vnet.ibm.com 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?9507162325.AA17210>