Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:3028 comp.os.linux.misc:21084 Newsgroups: comp.os.386bsd.misc,comp.os.linux.misc Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msuinfo!agate!trib.apple.com!amd!netcomsv!calcite!vjs From: vjs@calcite.rhyolite.com (Vernon Schryver) Subject: Re: source of TCP/IP (was I hope this wont ignite a major flame ...) Message-ID: <Cu0L6w.Ms1@calcite.rhyolite.com> Organization: Rhyolite Software Date: Thu, 4 Aug 1994 14:20:55 GMT References: <31od8d$15l@fw.novatel.ca> <31pc9l$ctp@oscar.agcs.com> Lines: 66 In article <31pc9l$ctp@oscar.agcs.com> robertsw@agcs.com (Wallace Roberts) writes: >hpeyerl@sidney.novatel.ca (Herb Peyerl) writes: > ... >>This is an example of some of the Linux device-drivers I've seen: >> >> short error = rx_status & 0x3C00; >> outw(inw(ioaddr + 0x0A) | 0x00C0, ioaddr + 0x0A); >> >>As far as I can tell; Linux Ethernet device-drivers were written in >>Write-Only-C. There are no comments in the surrounding code that in any >>way indicates exactly what "0x3c00", "0x0a", "0x00c0" actually mean. To >>people without docs (usually these are the people who are trying to fix >>the code) the above is completely meaningless. > >if you're writing (or fixing) a device driver, you are expected to have >the h/w manuals handy. comments are unnecessary if you have the device >manual & understand the h/w. this is the expected level of competence >for a programmer writing or fixing a device driver. > >"if you can't run with the big dogs, stay on the porch..." If you had any significant professional experience, you'd know that is "horse pucky." In real life, you often, probably usually do not have the manual when you need to make a fix. You usually must write drivers based on the wrong manual and sometimes no manual at all. (Spare me your claims of professional competance. I've earning my living at this for more than 25 years.) I'm not one of those who think that all hex numbers need #define's; a value that's used only once need only be commented. >>Thank you; I'll stick to working on code that I can actually read. > >you're welcome. now run along and play... Wrong. People who write garbage code like that are amatuers who won't get the job offers from outfits worth working for. Garbage code like that quoted above is why it's always a good idea to ask candidates to bring a code fragment and a piece of English. Even if they borrow someone else's, it's nice to know they can recognize competant work, or at least know the value of asking someone who can. When you're interviewing, it doesn't hurt to see if the outfit is a bunch of bozos who follow the lastest Management and Human Resources Science fads and latest Object Oriented Structured Computer Science Software Engineering mavens instead of doing good work. Watch for bureaucratic English and junk code. Fooey. After a previous posting expressing awe about Linux, I was able to avoid observing that only an amatuer would have lots of awe for someone who has rewritten an existing system. Professionals, whether shipwrights, carpenters, or programmers, often repeat things. Customers rarely want something new. Any competant journeyman can make a clone of anything, given only the documentation, tools, and materials, build it faster than the original was built, and produce something better than the original. It doesn't take a master, only a journeyman or apprentice. Only amatuers get excited about something that professionals consider a good but boring training exercise. Linux may be a reasonable piece of work, although that manure code above is not a good sign. It may have been done professionally (ie. quicker and better than the original). Its existence is good because it helps supress lawyerscum. However, its author(s) have done no more than demonstrate reasonable competance. Vernon Schryver vjs@rhyolite.com