Path: utzoo!attcan!uunet!samsung!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!minya!jc From: jc@minya.UUCP (John Chambers) Newsgroups: comp.unix.wizards Subject: Re: What SHOULD go in the kernel Keywords: device drivers Message-ID: <42@minya.UUCP> Date: 28 Oct 89 17:30:36 GMT References: <2186@ektools.UUCP> <47040@bbn.COM> Distribution: na Organization: home Lines: 68 In article <47040@bbn.COM>, news@bbn.COM (News system owner ID) writes: > jwr@ektools.UUCP (Jim Reid) writes: > < Is there a rule of thumb of what should and should not be put in the > < kernel? To be more specific, is it better to make a device driver > < 'lean-and-mean' or sophisticated, so that the user interface (the read(), > < write(), ioctl()) is simpler? > > As little as possible?. (both a statement and a question) > > First off, kernels are generally harder to debug than user programs, > so the less stuff you add there the better off you will be. Also, > most kernels won't do VM on themselves (for several _good_ reasons > :-) ), so any extra code you put in the kernel will be sitting there > taking up space even if you don't need it right now. [This is too good to pass up. ;-] I'd like to observe that, though this may be correct from a software-engineering point of view, it is incorrect from a career-interest point of view. I've made the mistake of minimizing the kernel work on quite a few projects. Now when I go to interviews, it is clear what the result is. Such design isn't ever taken as evidence of practicality, good engineering practice, or any such thing. It is merely evidence that I am a Unix kernel lightweight. At a time when Unix-kernel/device-driver experts are getting roughly 50% more bucks than those who work at the "application" level, it is clear what a fool I've been. Lately, I've been following people's advice here, and writing programs that grovel around in a filesystem's raw device. This could turn out to be a bad idea. Once again, I've done it outside the kernel. But I have an excuse: This is an object-only system. If I had the source, you bet I'd do it in the kernel (especially since in this case, it'd be easier). > Personally, I'd go for lean and mean just 'cause. Very seldom is fat > and featureful better than lean and mean, especially in a kernel. > Compare, for instance, v9 and SunOS 4. (yes, it _is_ an often > repeated cheap shot at Sun, but it's also _true_.) In particular, there's a good demand for people with significant Sun internals experience. It can be hard to get this experience, due to the shortage of source code at most Sun customer sites. If you have it available, the sensible advice is "Go for it." If you have doubts about whether it's for the best of your current employees, you might try asking them whether they'd pay more for a Sun internals expert than for a Sun applications programmer. Then go with their answer. > -- Paul Placeway > Am I a wizard? Are you qualified to judge? Does it really > matter in the end? "What I am is what I am, are you what > you are or what?" -- E.B. In the current economy, much judging is done by those unqualified to judge. That's why there's so much dependence on credentials. It's hard to see how it could be any other way in a field with such rapid technology change. In response to the expected flames, I'll just pre-ask a pertinent question: If you want a job done right, shouldn't you be rewarding those who do it right, rather than those that do it the hard way? (I might also observe that Mach may bad news for kernel experts; it seems they've moved a lot of stuff out of the kernel.... ;-) -- #echo 'Opinions Copyright 1989 by John Chambers; for licensing information contact:' echo ' John Chambers <{adelie,ima,mit-eddie}!minya!{jc,root}> (617/484-6393)' echo '' saying