Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry From: terry@cs.weber.edu (A Wizard of Earth C) Subject: Re: BSD/386 Commercial Product Message-ID: <1993Jul29.010758.7774@fcom.cc.utah.edu> Sender: news@fcom.cc.utah.edu Organization: Weber State University, Ogden, UT References: <1993Jul27.053721.6646@spcvxb.spc.edu> <1993Jul28.035328.2892@fcom.cc.utah.edu> <1993Jul28.025606.6655@spcvxb.spc.edu> Date: Thu, 29 Jul 93 01:07:58 GMT Lines: 123 In article <1993Jul28.025606.6655@spcvxb.spc.edu> terry@spcvxb.spc.edu (Terry Kennedy, Operations Mgr.) writes: >In article <1993Jul28.035328.2892@fcom.cc.utah.edu>, terry@cs.weber.edu (A Wizard of Earth C) writes: > 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. I kinda lean toward "all of them". >> 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? Yes, precisely where it is most useful. > 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. Developement is much faster if you don't have to reboot each iteration; this assumes you don't crash. It is also possible to load two modules and use these as hooks to do the developement in user space -- where you can use your source level debugger. I refer you to the Heidemann (UCLA) and Rosenthal (USENIX) papers. Using loading/unloading of your file system (assuming you skeletonize it first instead of trying to write everything and then just debug the crashes), you can speed up your developement by one reboot cycle/developement environment rebuild per load which doesn't cause a crash. If you do user space developement, typically, you won't crash at all. As far as where this is useful in the real world, consider a kernel that, as distributed, is small but can support all supported devices on an OS through demand loading of modules (only the probe routine needs to be in the kernel itself, with basic I/O to get it and modiles loaded). Consider that you can update your ethernet driver without shutting the machine down. Consider that loadable modules is how Sun distributes its SPARCPrinter software by default. Note that you can distribute kernel extensions and even fixes to existing kernel code as loaded modules... again, without taking the machine down. If I want to use SLIP where I haven't before, I just cause it to be loaded into my kernel and start using it, instead of reconfiging, rebuilding, and rebooting. Your refutation of the printer driver example by saying "well it's already in my kernel" is valid only for your case of having thought ahead for everything -- nobody thinks ahead for every possible configuration; if they do, their kernel is so large and so full of code paths that are never executed that the quickly find themselves on the downside of the cost/benefit curve. >> 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) For SCO Xenix -- all of them. For ISC UNIX 3.1 (the one I was interested in running binaries from) most of them. I can't distribute the ISC code because it's derived from some unclean sources. And now that we have a console driver that emulates the SCO console driver, a little hacking lets me run the commercial version of WordPerfect on my machine... and SCO Professional (a Lotus clone) and SCO FoxBase (a DBase III+ clone). I still ned more hacking for the serial drivers, but I fully expect to be able to run the Xenix386 version of TERM (a commercial comm package by Century Software). I find this extremely exciting. There is very little commercial software for BSD/386 compared to SCO Xenix. >>> 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... They'll be available when they are available. Shared libs in one form or another have been around for about 8 months but unsuitable for X -- the primary use everyone but people who are "playing around" want to put them to (I define "playing around" to include 30MB or smaller drives). The Joerg implementation that "pollutes" the address space and the LKM code (I am informed) will be part of 386BSD 0.2. If you agree to the research nature of 386BSD, you shouldn't object to the patchkit as a distribution mechanism. On the other hand, most of the projects have set up for SUP. I am not in a position to drop new code out; however, my shlib implementation is available as soon as I am in such a position. The SunOS shlibs are available as soon as "BSD4.4 Lite" is allowed to ship or when Sun donates the code publically as opposed to just to UCB's CSRG, since I had this working well before the restrictions on what I can do went in. Suffice it to say both implementations allow shared X libraries without the problems in initialized data that plague the Joerg code. I am under simlar restrictions on the Xenix compatability code (it requires my exec changes and my proc changes, which I have described to various news groups and mailing lists). The LKM stuff is in the "NetBSD current" tree; if SUP counts as a distribution mechanism instead of a "patchkit or similar", then it's available now. I like research; it's where I want to be. I understand the derivitive work restrictions a commercial OS has to have. GNU has similar restrictions going the other direction. That's why I'm on the *BSD bandwagon. Terry Lambert terry@icarus.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.