Return to BSD News archive
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!haven.umd.edu!uunet!spcvxb!terry From: terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) Newsgroups: comp.os.386bsd.misc Subject: Re: BSD/386 Commercial Product Message-ID: <1993Jul28.025606.6655@spcvxb.spc.edu> Date: 28 Jul 93 02:56:06 EDT References: <1778.2C53F9EF@mechanic.fidonet.org> <23136o$aa6@pdq.coe.montana.edu> <1993Jul27.053721.6646@spcvxb.spc.edu> <1993Jul28.035328.2892@fcom.cc.utah.edu> Organization: St. Peter's College, US Lines: 70 In article <1993Jul28.035328.2892@fcom.cc.utah.edu>, terry@cs.weber.edu (A Wizard of Earth C) writes: > Not many CSRG drivers out there (or any BSD4.4 Lite, for that matter). Not > to complain, but if you want to be where the drivers are, you need a kernel > that can run Linux or 386BSD/NetBSD/FreeBSD drivers. I believe those have already diverged (or not converged, in the case of Linux). At least that's what I've read in the 386bsd newsgroups from some of the responsible folks. 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. > 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? > 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. > An execution class is basically a program loader. For instance, using code > I can't give out, I can run ISC 386 and SCO Xenix binaries on my machine > (if I'd spent another week, the Xenix stuff would be distributable) as long > as they are statically linked. This is certainly interesting. What percentage of these binaries are static- ally linked? (Out of curiousity - I really don't know the answer) > I wouldn't either; but I wouldn't call it a research OS either, and that's > the primary motivator for the *BSD efforts. BSD/386 is an applications > platform. No disagreement there. >> I'd be quite surprised if any of these things make it out in an official >>"free" release first. > > Suprise. Xenix Compatability and shared libs. Maybe not SPARC, but then > again maybe (we'll see). In any case, Amiga and several ther ports exist > in Beta (Macintosh?), and others are planned or starting coding. Will that be in 386bsd 0.2, or NetBSD 1.0, or...? Note that I meant a com- plete official "free" release, suitable for installing from scratch, not as a patchkit or similar... > Don't underestimate free. I don't. However, don't dismiss BSD/386 just because it's commercial. [This is directed at the general audience, not anybody in particular, by the way] Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA terry@spcvxa.spc.edu +1 201 915 9381