Return to BSD News archive
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!darkstar.UCSC.EDU!news.hal.COM!olivea!charnel.ecst.csuchico.edu!xmission!u.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (Terry Lambert) Newsgroups: comp.os.386bsd.misc Subject: Re: Usefulness of BSD/Linux Source Knowledg Date: 28 Jul 1994 04:03:52 GMT Organization: Weber State University, Ogden, UT Lines: 77 Message-ID: <317an8$h8u@u.cc.utah.edu> References: <cln.775305310@dynamo> <316kug$ea9@wsiserv.informatik.uni-tuebingen.de> NNTP-Posting-Host: cs.weber.edu In article <316kug$ea9@wsiserv.informatik.uni-tuebingen.de> gabara@Informatik.Uni-Tuebingen.DE writes: ] BSD has not developed a lot during 10 years. No dynamic loading of device ] drivers. I really like how IBM AIX does this. You install a drive by putting ] in the hardware, reboot, and voila, the system detects the drive, sets up the ] device files in /dev, dynamically loads the device driver, and you're set. ] The logical volumes are way cool. Have you ever created partitions for BSD? ] When you run out of space of one partition, how do you enlarge it? Easy ;-) ] backup the drive, change the partition sizes, and do a restore (taking hours ] at least). The AIX filesystem sizes grow on demand (since they are virtual, ] somewhat like virtual memory). People think this causes a lot of overhead, ] but I foud the AIX filesystem extremely fast. You have lumped a bunch of issues together here; let me try to sort them out and respond to them: 1) Dynamically loadable kernel modules I wrote this code and released it at the start of 1993 prior to the Novell acquisition of USL. It's in NetBSD right now (with fixes by Chris), and is easily installable into FreeBSD. Unlike your AIX version, you don't have to reboot to install or deinstall file systems, drivers, pseudo-devices, system call extensions, or "misc" modules (modification of kernel structures and function pointers). 2) Autoconfiguration of "dev" devices. There are two approaches to this; the first is a postinstall script for the module loader; this works now. The second approach is a device file system; this has been discussed, experimentally implemented, and suggested on the mailing lists that it will be included in FreeBSD 2.0. I am positive the NetBSD crew have aspirations in this direction as well. 3) Virtual volume management. This has been discussed, but not formally pursued, by many people (like Phil Neiswanger and me). To deal with this first requires dealing with DOS partition management, since any such virtual management will have to take place in DOS partitions anyway if BSD is to coexist. This is further complicated by the fact that existing file systems (like the Linux, DOS, and HPFS) from those other systems will not undergo the same management, yet must still be accessable. This means a stage raw driver, and (if SCSI LUNs are to be supported) an increase in the minor device name space (from 16 to 32 bits). 4) File system expansion. This is not necessarily desirable; the allocation of 4M units at a time without respect to their position on the disk relative to the partition being added to destroys the locality of reference assumtions in UFS, as well as requiring tables that are *not* currently dynamic become dynamic (specifically, it horribly impacts bad sector replacement and requires per 4M hunk virtualization of the superblock structures. Yes, it is a sexy feature, but volume striping and block replication are more useful, and the AIX approach only provides crude striping. The Journaling capabilities are more interesting, but are available elsewhere. Now this is just 4 points; there are many, many other areas of research to examine, and in many of them, tremendous (and critical) progress has been made. I'm sure others would be happy to help address them on a case by case basis, if you wanted. Regards, Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.