Date: Wed, 20 Mar 1996 16:40:35 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: gpalmer@FreeBSD.ORG (Gary Palmer) Cc: terry@lambert.org, freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a damn 2nd disk Message-ID: <199603202340.QAA28107@phaeton.artisoft.com> In-Reply-To: <352.827361889@palmer.demon.co.uk> from "Gary Palmer" at Mar 20, 96 10:44:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > This baically leaves default sector sparing settings, sector counts > > designed to be on (no longer applicable) cylinder boundries, and > > slice geometries that should be interactively determined instead > > of frozen in an obsolete data file. > > > The disktab should go. > > So how do you want to deal with the automatic generation of floppies > during ``make release''? It sure as **** shouldn't be ``interactively > determined''. Sure, kill disktab for hard drive use, but I say keep it > (perhaps in a ``cut down'' format) for floppies. The disklabel program (which should go, too, in favor of a more generic mechanism not dependent on the BSD partitioning scheme) ought to issue an ioctl to the open disk device to query it for default paramters. For non-default parameters, they should be in the makefile as arguments. The eventual replacement should be a more generic tool. It would operate by: 1) Open /dev/dsk on the devfs. 2) Issue ioctl's to determine allowable logical-to-phyisical mapping schemas. 3) Present a menu of available schemas to apply at the device level. For instance, the menu for /dev/dsk/c0d0t0 (controller zero, disk zero, lun zero) would include: a) Leave device unpartitioned for use as a file system b) Add DOS partitioning to device c) Add BSD (Disklabel I) partitioning to device d) Add Solaris (Disklabel II) partitioning to device 4) If the user selected "b", then an ioctl would be made to cause a DOS partition table to be written to the raw device, and the user would be called upon to arrange space into DOS partitions. 5) For each DOS partition the logical device driver for DOS partitions saw as a result of a callback from the ioctl to write the partition information, a /dev/dsk/c0d0t0/p<#> is attached in the devfs framework. 6) Again, you can present a menu, this time for DOS partition 1 (/dev/dsk/c0d0t0/p0): a) Leave device unpartitioned for use as a file system b) Add DOS extended partitioning to device c) Add BSD (Disklabel I) partitioning to device d) Add Solaris (Disklabel II) partitioning to device (Note: Item 'b' has been changed). 7) And so on... Such a tool would have no partitioning-scheme-specific knowledge: that is, it would have no idea of what a disklabel was, other than the text string (or string identifier, if we allow language localization) that a logical device driver to present at the user interface. The tool would operate in three modes: 1) As a command line tool: <toolname> <command> [<arguments>...] After each invocation, the tool would return its results and exit. This is suitable for use in shell scripts, etc. 2) As an interactive tool: <toolname> If invoked with no arguments, it would present the prompt "toolname> " and take the exact same commands. The command "exit" and <EOF> would have the effect of causing the tool to exit (in the command line mode, "<toolanme> exit" would return causing no modifications). 3) As a command channel. In this mode, a pipe will be established to stdin and stdout, and the tool may be programatically interrogated. The main difference is that there is no prompt if the tool stats it's stdin and finds it to be a pipe (which it will only do if it has no arguments). Structural hierarchy commands must be issuable to list the available options. Basically, a tool which runs this way can be used in a shell script during interactive installation, or can be opened by a "tool shell" GUI interface... that is, a GUI program that knows how to talk to this class of tools, and presents a user interface that is data driven off a standard set of queries which can be made to this class of tools. You write one GUI program and several tools programs and you have full GUI-based system administration -- for nearly free. Obviously, mode #3 requires some substantial work on command status API definition. It also requires the ability to have command sets as transactions. For instance, I could have an interarctive session: phaeton# toolname toolname> partition /dev/c0d0t0 DOS toolname: success toolname> add /dev/c0d0t0 0 400M toolname: success toolname> begin toolname: logging mode; use "commit" or "cancel" to stop logging toolname> partition /dev/c0d0t0/p0 BSD toolname> add /dev/c0d0t0/p0 0 100M toolname> add /dev/c0d0t0/p0 1 32M toolname> add /dev/c0d0t0/p0 2 268M toolname> commit toolname: commit: partition /dev/c0d0t0/p0 BSD toolname: commit: add /dev/c0d0t0/p0 0 100M toolname: commit: add /dev/c0d0t0/p0 1 32M toolname: commit: add /dev/c0d0t0/p0 2 268M toolname: success toolname> exit phaeton# newfs /dev/c0d0t0/p0/s0 [ ... ] phaeton# newfs /dev/c0d0t0/p0/s2 [ ... ] Clearly, "commit" and "cancel" refer to the "OK" and "Cancel" buttons in the dialog for "create a BSD partition" (with an input field set to 400M) that lets you carve up a BSD installation into a standard DOS partition. Unfortunately, without devfs, I haven't really spent the necessary time to figure out the GUI-related syntax for a nice, usable presentation (slider bars for partition sizing, etc.) that the tool would have to be able to present, or the query syntax to get it to present it based on the kernel logical device drivers present. Getting back to floppies: phaeton# toolname toolname> partition /dev/dsk/fd0 BSD toolname: success toolname> add /dev/dsk/fd0 3 ALL toolname: success toolname> exit Or, in shell script form: toolname partition /dev/dsk/fd0 BSD toolname add /dev/dsk/fd0 3 ALL newfs /dev/dsk/fd0/3 Obviously, there would be difference for bootable floppies; specifically, there would be a boot space reservation argument to the "partition" command... basically, something like "+8192" to the disk name to give a raw offset (worst case: just as in -current, a dummy DOS partition table would be written in the second stage boot as a "partitioning" method, and DOS partitions would be used to achieve the offset). Regards, Terry Lambert terry@lambert.org --- 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?199603202340.QAA28107>