Return to BSD News archive
Newsgroups: comp.os.386bsd.development Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!moe.ksu.ksu.edu!zaphod.mps.ohio-state.edu!swrinde!gatech!concert!sas!mozart.unx.sas.com!torpid.unx.sas.com!sastdr From: sastdr@torpid.unx.sas.com (Thomas David Rivers) Subject: Re: Some ideas on the driver interface (was: Re: Release of drivers etc.) Sender: news@unx.sas.com (Noter of Newsworthy Events) Message-ID: <C3qMGD.Ez7@unx.sas.com> Date: Thu, 11 Mar 1993 18:38:36 GMT References: <C3MCIF.Iv@sugar.neosoft.com> <1nj0ej$j6s@walt.ee.pdx.edu> <0bcN02Do3ab301@JUTS.ccc.amdahl.com> Nntp-Posting-Host: torpid.unx.sas.com Organization: SAS Institute Inc. Lines: 73 In article <0bcN02Do3ab301@JUTS.ccc.amdahl.com> gab10@cd.amdahl.com (Gary A Browning) writes: >In article <1nj0ej$j6s@walt.ee.pdx.edu>, rgrimes@acacia (Rodney W. >Grimes) writes: >> peter@NeoSoft.com (Peter da Silva) writes: >> : It would probably be best to integrate the master file and the >> BSD-ish config >> : file somehow... maybe: >> : >> : controller wd0 at isa? port "IO_WD1" bio irq 14 vector wdintr >> : disk wd0 at wd0 drive 0 >> : device wd0 at major 0 minor wd0a 0 wd0b 1 wd0c 2 wd0d 3... >> : disk wd1 at wd1 drive 1 >> : device wd1 at major 1 minor wd1a 8 wd1b 9 wd1c 10 wd1d 11... >> : >> : [rest of example deleted] >> >> You really want to duplicate /dev/MAKEDEV in every kernel config file? >> That >> sounds like storing duplicate data. > >Shouldn't /dev/MAKEDEV be built by the kernel building process? Maybe by >config. I think you already have duplicated data, just not in a form that >is easy to keep coordinated and up-to-date. > The problem here is there are two ideas floating around; the idea of *building* a kernel, vs. the idea of *installing* a kernel. >> Are you advocating that config do mknod's in /dev? That would mean every >> time you config a kernel /dev would get rebuilt. Seems to be a waste. > >Every time you install a kernel /dev *should* match the config. You can either >rebuild or alter it to match, but it should be match. On some other >implementations of Unix, installation of a new kernel is more complicated than >simply copying the kernel over /386bsd. On UTS, reconfiguring a kernel will >cause /dev/to be rebuild, /etc/fstab to be rebuild along with some other >config dependent files that we don't have in 386BSD. Maybe 'config' should >do more towards maintaining a coherent system. > >-- >Gary Browning | Exhilaration is that feeling you get just after a >gab10@cd.amdahl.com | great idea hits you, and just before you realize > | what is wrong with it. What we probably need is something that "builds" a kernel; puts that kernel and related information (i.e. something that describes the built devices, and the init file (since it could change), etc...) into a "known" location of kernels. Another program comes along and says "Oh, you have some built kernels lying around; would you like to install one." It the copies the kernel to the correct place, and builds a new /dev/MAKEDEV, etc... It *also* places a marker (say a file in /) that indicates that on reboot, /dev/MAKEDEV needs to be run.... Then, when the new kernel is booted, /etc/rc notices the marker and runs /dev/MAKEDEV, then deletes the marker... POOF - you're new kernel is up and running. [There are probably problems with changing the boot device ...] I didn't think of this idea, it's how ISC UNIX rebuilds and installs new kernels (the idbuild and install commands.) - Dave Rivers - (rivers@ponds.uucp (home)) (sastdr@unx.sas.com (work)) -- UPDATE ALL INFORMATION AND POD INTO COSMOS - Federal Express