Date: Wed, 30 Apr 1997 15:30:10 +0930 (CST) From: Michael Smith <msmith@atrad.adelaide.edu.au> To: Shimon@i-Connect.Net (Simon Shapiro) Cc: msmith@atrad.adelaide.edu.au, julian@whistle.com, freebsd-hackers@freebsd.org, jkh@time.cdrom.com Subject: Re: Continual Education (was Re: A Desparate Plea) Message-ID: <199704300600.PAA26367@genesis.atrad.adelaide.edu.au> In-Reply-To: <XFMail.970429224020.Shimon@i-Connect.Net> from Simon Shapiro at "Apr 29, 97 10:11:09 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Simon Shapiro stands accused of saying: > > > I normally ensure that development kernels don't use LKMs; if I need > > stuff I'll pull it in statically. Generally a development kernel will > > be extremely aggressively stripped down to minimise possible conflicts. > > How? How do I take a kernel piece (module, driver, etc.) that is an LKM and > make it into a kernel static part? Most of the LKM's are actually kernel pieces that have been ripped out and made into modules. If you have NFS, CD9660, LINUX etc. in your kernel config as options, the LKM's aren't required. > >From this question, derived is the next: Being that FreeBSD is available in > source and that the config file is so simple (Yes, one could build a tcl/tk > interface to it to compete with linux make xconfig), why bother with LKM's? > Especially when they do not to load/unload in a friendly manner. A relevant question. Most LKMs are loaded once and never unloaded; these aren't a problem source. The LKM framework was a bit of a kludge at the time, and has perhaps not been brought completely up to snuff simply because it worked "well enough". Doug Rabson is currently working on a completely new and improved LKM scheme, and would no doubt welcome any input or contribution(s) you felt worthwhile. > With memory prices being what they are, a ``huge'' kernel will cost about > $8.00 more than a tiny one. Ebmedded systems? commercial non-source > products? The latter is a very attractive reason for supporting LKMs. A good LKM scheme will also allow non-build-literate users to add/remove options without having to have the source handy. > This is not necessarily a criticism of the threads library. We had > to twist it a bit; It ran 256 threads over more than a thousand file > descriptors with heavy TCP load. I think it would be fair to suggest that the MIT pthreads code was never designed for that sort of load. 8) FreeBSD's fork/exec/IPC performance is pretty good, so it's not too surprising that your results were better with that approach. > Simon -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704300600.PAA26367>