From owner-freebsd-hackers Mon Mar 24 18:31:58 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id SAA01194 for hackers-outgoing; Mon, 24 Mar 1997 18:31:58 -0800 (PST) Received: from who.cdrom.com (who.cdrom.com [204.216.27.3]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA01114 for ; Mon, 24 Mar 1997 18:31:50 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.50]) by who.cdrom.com (8.8.5/8.6.11) with SMTP id RAA16714 for ; Mon, 24 Mar 1997 17:58:28 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA24346; Mon, 24 Mar 1997 18:42:12 -0700 From: Terry Lambert Message-Id: <199703250142.SAA24346@phaeton.artisoft.com> Subject: Re: dump for MS-DOS partitions. To: thorpej@nas.nasa.gov Date: Mon, 24 Mar 1997 18:42:12 -0700 (MST) Cc: darrenr@cyber.com.au, christos@nyc.deshaw.com, port-i386@netbsd.org, hackers@freebsd.org In-Reply-To: <199703242353.PAA10711@lestat.nas.nasa.gov> from "Jason Thorpe" at Mar 24, 97 03:52:59 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > NetBSD has already changed at least fsck to fsck_ffs ... fsck is now a > "wrapper" much like mount is. > > Eventually, we will have: > > newfs_ffs > dump_ffs > fsck_ffs > mount_ffs > > newfs_lfs > dump_lfs > fsck_lfs > mount_lfs Yes; I've been suggesting it for years... it's a good idea. One problem is that it wasn't too useful until the mount system call changes, and that didn't happen until 4.4 because we feared changing things that might get touched by the Lite2 integration (unreasonably, IMO). Other than inverting the name/program convention so all my ffs_ stuff will show in one area, all my mfs in one area, etc... I also wanted ffs_fstype. The fstype wrapper would call all available functions iteratively to identify the FS on a given device. Ideally, this would be implemented via VFS_IDENT() in each FS, and the kernel code would be responsible for recognition. Obviously, VFS_MOUNT would call VFS_IDENT internally. You would get at the IDENT either by calling mount with a "don't really" argument, or by ioctl'ing down to the device (and the disk device knowing the ioctl means iterate the installed FS types to identify the device). Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.