Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!europa.eng.gtefsd.com!emory!ogicse!usenet.ee.pdx.edu!acacia!rgrimes From: rgrimes@acacia (Rodney W. Grimes) Newsgroups: comp.os.386bsd.development Subject: Re: Some ideas on the driver interface (was: Re: Release of drivers etc.) Message-ID: <1nofv5$rll@walt.ee.pdx.edu> Date: 11 Mar 93 22:54:28 GMT Article-I.D.: walt.1nofv5$rll References: <0bcN02Do3ab301@JUTS.ccc.amdahl.com> Organization: Portland State University Lines: 59 NNTP-Posting-Host: acacia.cs.pdx.edu 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. NO it should not, as was posted in another article, if you screw with majors in /dev and the current kernel is going to become ill!! I agree that the data is in conf.c, almost even usable (just need to add a name field and support for minors), But this information should be pretty static, once we get conf.c and /dev/MAKEDEV up to snuff most of the stuff people are complainig about well go away. I have prepared and submitted a rather large replacement patchset to Jordan that brings conf.c and /dev/MAKEDEV almost up to date. I am still working on a few more additions and then this whole issue should go away until more new drivers are written. I won't go into details yet as I am waiting on Jordan to reply to my patch. : : > 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. config should not do it, if it is put anyware it should go into the kernel Makefile as an install target, thus it would occur when the kernel was installed, not when it was configed. config could be altered to emit a MAKEDEV in the kernel build directory to help with this, but then we need all the rules for minors as well. My real feelings on this is that the current implementaion is workable as long as we can coordinate additions to conf.c, Jordan is now assigning slots so the issue of stepping on each other is less likely.. -- rgrimes@agora.rain.com