Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!elroy.jpl.nasa.gov!decwrl!usenet.coe.montana.edu!osyjm From: osyjm@erc.montana.edu (Jaye Mathisen) Newsgroups: comp.os.386bsd.misc Subject: Re: BSD/386 Commercial Product Date: 29 Jul 1993 01:10:35 GMT Organization: /psoft/Local/lib/MYORG Lines: 65 Message-ID: <23782b$1vo@pdq.coe.montana.edu> References: <1778.2C53F9EF@mechanic.fidonet.org> <1993Jul27.053721.6646@spcvxb.spc.edu> <1993Jul28.035328.2892@fcom.cc.utah.edu> <1993Jul28.025606.6655@spcvxb.spc.edu> NNTP-Posting-Host: erchp1.erc.montana.edu In article <1993Jul28.025606.6655@spcvxb.spc.edu>, Terry Kennedy, Operations Mgr. <terry@spcvxb.spc.edu> wrote: > > I haven't yet seen any drivers that I'd need/want that aren't already in >BSD/386. Perhaps that just proves that BSD/386 is an excellent fit for my >needs. Anybody have any examples? I've already seen the "anything but Adap- >tec" request. What I haven't seen is a clear "winner" of what the next SCSI >controller supported should be. Case in point, the 386bsd DEPCA driver for the DEC DEPCA card doesn't "drop right in". Which is one of the things kind-of holding me back here from committing the University to it. (It should be noted that one of the dudes at BSDI has offered to help me get it going. It may be easy, I'm just not up on this autoconfigure stuff as I find it completely uninteresting... :) The people working on the *bsd stuff seem to get a number of requests for Ultrastor support, but I'm sure the % of people using those as opposed to adaptec is minimal. Sony CD31A CDROM support would be nice. A driver is almost done for *bsd. Somebody is or has just about wrapped up a Mitsumi driver for *bsd, so that one is covered as well. On the otherhand, BSD/386 sure seems to run a lot better on seemingly more motherboards... > >> LKM is "Loadable Kernel Modules".. it allows you to load/unload device >> drivers, file systems, system calls, execution classes, streams modules, >> and misc modules (basically, anything you can wedge a hack into in the >> kernel address space) without taking the system down. And modules loaded >> take kernel memory, and are not affected by initial kernel size. > > I'm sure this is very interesting, particularly in a development environ- >ment. What benefits would these give me in an application development (or >deployment) environment? OS updates can be done on the fly, which maybe a handy way to fix bugs in the OS, say in ethernet drivers, or other things of that general kind. I think Terry mentioned once that he had a machine that had been up for 63 days, but had almost all the kernel software replaced one hunk at a time using LKM... Don't quote me on that though. > >> For instance, say I bought a printer and wanted to get it running. I could >> install the interruptless printer driver without taking my machine down. > > But I have already configured my kernel with lp support, even though I don't >have a parallel printer on it (though I might in the future). > > Please don't misunderstand - I'm perfectly willing to be convinced. I just >don't "get it" from the examples you cite. Currently, if I were developing a >new filesystem, I'd do it on a test machine (probably accompanied by frequent >crashes 8-) and when I had something solid (or at least Jello-like) I'd plop >it into a "light duty" production system. All true. But suppose you find a bug in your lp driver. rebuild a new one, and replace the currently running one. No reboots. Stuff like that becomes possible with the LKM stuff. I suspect that frankly, the possibilities are endless, I just need more imagination. -- Jaye Mathisen, COE Systems Manager (406) 994-4780 410 Roberts Hall,Dept. of Computer Science Montana State University,Bozeman MT 59717 osyjm@cs.montana.edu