BABYL OPTIONS: -*- rmail -*- Version: 5 Labels: Note: This is the header of an rmail file. Note: If you are seeing it in rmail, Note: it means the file has no messages in it.  1,, Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA17363; Wed, 16 Jul 97 23:36:51 EDT Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA11379; Wed, 16 Jul 97 23:35:25 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id XAA29920; Wed, 16 Jul 1997 23:36:39 -0400 Date: Wed, 16 Jul 1997 23:36:39 -0400 Message-Id: <199707170336.XAA29920@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: kwrohrer@uiuc.edu Cc: bofh@snoopy.virtual.net.au, linux-kernel@vger.rutgers.edu In-Reply-To: Keith Rohrer's message of Wed, 16 Jul 1997 19:59:54 -0500 (CDT), <199707170059.TAA00494@jadrek.kwr.uiuc.edu> Subject: Re: Take a deep breath... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 *** EOOH *** Date: Wed, 16 Jul 1997 23:36:39 -0400 From: "Theodore Y. Ts'o" To: kwrohrer@uiuc.edu Cc: bofh@snoopy.virtual.net.au, linux-kernel@vger.rutgers.edu In-Reply-To: Keith Rohrer's message of Wed, 16 Jul 1997 19:59:54 -0500 (CDT), <199707170059.TAA00494@jadrek.kwr.uiuc.edu> Subject: Re: Take a deep breath... Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: Keith Rohrer Date: Wed, 16 Jul 1997 19:59:54 -0500 (CDT) In "traditional" programming situations, I strongly hold to "*You* shall comment what you write, especially its interface." It's much easier for an author to write what he means by his code in natural language, while he still remembers what he was doing, than for that same programmer to go back and remember things later, or for a third party to have to figure things out from scratch. In cases where the code being added to the main kernel distribution is "stable" or "perfect and complete the first time", it's sort of okay to let documentation slide; after all, "it works", and people who need to figure it out will learn more by figuring it out than by having it told to them. Likewise, when the chief programmers are viewed as some sort of gods, you don't want them writing the documentation so people don't blindly believe the inevitable bugs in it. ... All you say is true, and I do encourage the other Kernel developers to comment their code, and most especially there interfaces more. (I think I do a pretty good job of documenting the kernel code I write, although I'm obviously a biased source; I've had other people tell me that they think my code is relatively understandable and well commented, so there's so basis for my belief....) However, there's a flip side to this --- a distressing trend that I've been seeing --- which is that more and more programmers seem to be helpless without documentation. While it is a not a skill which most Computer Science departments teach (unfortunately!), it is extremely, extremely useful to be able to look at code that may not be particularly well documented, and figure out What's Going On. I call this the ability, for lack of a better name, "being able to jump between different levels of abstractions". It's a skill like any other where you get better with practice. One of my first and earliest ways I practiced this skill was disasembling Microsoft Basic on my CP/M machine. Sure, I had a disassembler which gave me the 8080 instructions, and marked out functions; but then I had to figure out what functions did, and once I figured out low-level functions, I would name them and try to figure out higher-level functions; other times knowledge of basically what a higher-levle function did would be enough to figure out what the lower-level function did. The basic trick is that once you figure out a particular function does, you make a mental model of what it appears to be doing at an abstract level, and then check your guess by seeing what functions call that particular function. Some people like to use fancy cross-referencing tools to look up this information. I personally simply use "grep func_name *.c". Sometimes, while looking at the callers to a particular function, I'll need to look at some other low-level functions which get called by the higher-level function. Then I try to figure out how the various low-level functions relate to one another. This whole process is a lot harder to explain than it is to actually do, once you get the knack of it. For example, it took me perhaps 10 or 15 minutes to figure out the new dcache interface. However, I probably spent less than 15-20 seconds at a time reading any one particular file. When you're figuring out an interface, it's natural to jump around between many different files, using grep and emacs's search function to quickly locate relevant pieces of code. In fact, during the initial stages, if you spend more than a minute or two looking at a file, you're in danger of concentrating too much on a particular tree instead of trying to figure out the general configuration of the forest. The reason why I call this "jumping between different levels of abstraction" is because as you jump from file to file, you need to adjust your thinking to an appropriate level of abstraction. At each level of abstraction, there are certain gaurantees made by the interface layers surrounding the abstraction layer (both above and below), and the abstraction layer will itself perform some abstract operation. While you're focusing on a particular abstraction layer, you won't care how a lower level function accomplishes its particular task --- only that it does do some abstract operation which is needed by the current abstraction level of interest. Of course, later, when you look at the lower level abstraction, you *will* care how it goes about its job. Hence, a flexible mind is needed to be able to rapidly refocus as you jump around. In fact, a very good analogy to consider is how your eyes look at some particular new landscape. A typical human will let their eyes skip all around the their field of view, stopping at each prominent landmark for perhaps 3-5 seconds before moving on. At each landmark, the eye will focus at the correct distance for that landmark, even if it means letting other objects (at different focal distances) go out of focus for a little while. While your eyes are doing all of this, your brain automatically integrates all of the input so that you end up with a coherent mental model of what's out there. I encourage budding kernel programmers to try to develop this skill. Not is it only useful for Linux development, but I think you will find it invaluable in your "Real World" jobs as well. First of all, often times in the "Real World" (as opposed to the idealized world of Computer Science Courses), code is often not well documented or commented. This is particularly true since many companies have these pesky deadlines which cause development staff to cut corners. Also, even if the code is well documented, the ability to quickly and easily jump between different levels of abstraction will allow you to more quickly master a new API and start using it. If any of you programmers want to someday become computer architects, start developing this skill right away. Rest assured it will come in handy many, many times during your career. - Ted  1,, Received: from SOUTH-STATION-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA23622; Thu, 17 Jul 97 01:13:49 EDT Received: from dledford.dialnet.net by MIT.EDU with SMTP id AA23031; Thu, 17 Jul 97 01:13:47 EDT Received: from dledford.dialnet.net (localhost [127.0.0.1]) by dledford.dialnet.net (8.8.5/8.8.4) with ESMTP id AAA28495 for ; Thu, 17 Jul 1997 00:13:44 -0500 Message-Id: <199707170513.AAA28495@dledford.dialnet.net> X-Mailer: exmh version 1.6.9 05/05/96 To: "Theodore Y. Ts'o" Subject: Re: Take a deep breath... In-Reply-To: Your message of "Wed, 16 Jul 1997 23:36:39 EDT." <199707170336.XAA29920@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 00:13:44 -0500 From: Doug Ledford *** EOOH *** X-Mailer: exmh version 1.6.9 05/05/96 To: "Theodore Y. Ts'o" Subject: Re: Take a deep breath... In-Reply-To: Your message of "Wed, 16 Jul 1997 23:36:39 EDT." <199707170336.XAA29920@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 00:13:44 -0500 From: Doug Ledford -------- [ Snipping a long explanation of jumping between abstraction levels ] An excellent piece of advice for many people out there. I would add one thing however, the ability to jump between abstraction levels, and consequently to understand how particular problems/actions must be performed is also invaluable to a person even if they don't have the source code. It's amazing how much knowing about the inner workings of the SCSI subsystem in linux helps me when diagnosing SCSI problems under NT or Win95 (not that I like these machines, but we do what we must :) This very ability took me from entry level computer technician to senior level computer technician in 8 months when I got my first computer job with a company as an on-site service/repair tech specializing in Windows/Novell networks. Therefore, to those people who might learn this skill, I would say that it adds just as much to their ability to work with (and denounce %^) the MicroSoft products as it does to understanding Linux. -- ***************************************************************************** * Doug Ledford * Unix, Novell, Dos, Windows 3.x, * * dledford@dialnet.net 873-DIAL * WfW, Windows 95 & NT Technician * * PPP access $14.95/month ***************************************** * Springfield, MO and surrounding * Usenet news, e-mail and shell account.* * communities. Sign-up online at * Web page creation and hosting, other * * 873-9000 V.34 * services available, call for info. * *****************************************************************************  1,, Received: from SOUTH-STATION-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA23689; Thu, 17 Jul 97 01:14:52 EDT Received: from dialup.duxbury.co.za by MIT.EDU with SMTP id AA23114; Thu, 17 Jul 97 01:14:46 EDT Received: (from mike@localhost) by devel.conexio.co.za (8.8.4/8.8.4) id HAA08780; Thu, 17 Jul 1997 07:11:48 +0200 Message-Id: <199707170511.HAA08780@devel.conexio.co.za> Date: Thu, 17 Jul 1997 07:11:47 +0200 (SAT) To: tytso@MIT.EDU Cc: linux-kernel@vger.rutgers.edu From: Mike Kilburn Subject: Re: Take a deep breath... In-Reply-To: <199707170336.XAA29920@dcl.MIT.EDU> X-Mailer: Ishmail 1.3.1-961106-linux Mime-Version: 1.0 Content-Type: text/plain *** EOOH *** Date: Thu, 17 Jul 1997 07:11:47 +0200 (SAT) To: tytso@MIT.EDU Cc: linux-kernel@vger.rutgers.edu From: Mike Kilburn Subject: Re: Take a deep breath... In-Reply-To: <199707170336.XAA29920@dcl.MIT.EDU> X-Mailer: Ishmail 1.3.1-961106-linux Mime-Version: 1.0 Content-Type: text/plain "Theodore Y. Ts'o" wrote: > > However, there's a flip side to this --- a distressing trend that I've > been seeing --- which is that more and more programmers seem to be > helpless without documentation. While it is a not a skill which most Another one is they cant fix code without the latest and greatest debugger/ICE/logic analyzer. If you cant figure out uncommented code and fix bugs without a logic analyzer/debugger then I dont want you on my team and you wont get hired by me. However, these tools should be provided whenever possible to increase productivity. Strange thing is it seems hardware guys and scientist and self-taught people dont have a problem with this when they turn into programmers, at least thats been my experience. I think their is a problem with universities computer science training for sure.  1,, Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA16283; Thu, 17 Jul 97 14:19:15 EDT Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA03292; Thu, 17 Jul 97 14:17:57 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id OAA20313; Thu, 17 Jul 1997 14:19:13 -0400 Date: Thu, 17 Jul 1997 14:19:13 -0400 Message-Id: <199707171819.OAA20313@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: "Andrew E. Mileski" Cc: fygrave@freenet.bishkek.su, linux-kernel@vger.rutgers.edu In-Reply-To: Andrew E. Mileski's message of Tue, 15 Jul 1997 23:23:57 -0400 (EDT), <199707160323.XAA00782@netcom.ca> Subject: Re: Take A deep Breath Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 *** EOOH *** Date: Thu, 17 Jul 1997 14:19:13 -0400 From: "Theodore Y. Ts'o" To: "Andrew E. Mileski" Cc: fygrave@freenet.bishkek.su, linux-kernel@vger.rutgers.edu In-Reply-To: Andrew E. Mileski's message of Tue, 15 Jul 1997 23:23:57 -0400 (EDT), <199707160323.XAA00782@netcom.ca> Subject: Re: Take A deep Breath Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 From: "Andrew E. Mileski" Date: Tue, 15 Jul 1997 23:23:57 -0400 (EDT) I agree, but the response from certain Linux developers is that "the source code is self documenting". Ya right. None of the kernel source code would pass a review at any company I know of, or even be accepted as a college/university assignment. You have a very highly idealized view of what code is like in commercial environments. I've talked to a number of folks who have a spent a lot of time working in such environments, and they've all told me that there's a lot of unbelievable crap out there, in software which you may be using every day. The issue is that in the "rush to market", there's often not time to do full debugging and coding and internal documentational. And after the code freeze deadline has been met, the next deadline, with features that have already been promised to customers by the salesmen, comes up so quickly there's often little time to clean up after the short cuts that were made to meet the *last* code deadline. This is why being able to read poorly documented code is a very important real world skill.... - Ted P.S. I myself have seen various OS source code from various big-name Unix manufacturers, and all I can say is that I have a fresh understanding why many of said companies either (a) don't want to show the source code to customers at all, and (b) want people who do look at the source code to agree to sign a NDA where in some cases they aren't even allowed to make any negative comments about the company......  1,, Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA08842; Thu, 17 Jul 97 19:59:17 EDT Received: from cloud9.net by MIT.EDU with SMTP id AA04009; Thu, 17 Jul 97 19:57:59 EDT Received: from jalvo.dialup.cloud9.net (jalvo.dialup.cloud9.net [168.100.204.55]) by cloud9.net (8.8.5/cloud9-1.1) with SMTP id TAA07997 for ; Thu, 17 Jul 1997 19:59:15 -0400 (EDT) From: jalvo@cloud9.net (John G. Alvord) To: tytso@MIT.EDU Subject: helpless without doc Date: Thu, 17 Jul 1997 23:59:10 GMT Organization: Bet Your Business Technologies Message-Id: <33ceb197.291596@CLOUD9.NET> X-Mailer: Forte Agent 1.10/16.436 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable *** EOOH *** From: jalvo@cloud9.net (John G. Alvord) To: tytso@MIT.EDU Subject: helpless without doc Date: Thu, 17 Jul 1997 23:59:10 GMT Organization: Bet Your Business Technologies X-Mailer: Forte Agent 1.10/16.436 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable absolutely... like a car mechanic who can't start working without a computerized aide guiding his steps. john  1,, Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA29894; Fri, 18 Jul 97 00:56:50 EDT Received: from ppp-h33.aracnet.com by MIT.EDU with SMTP id AA04653; Fri, 18 Jul 97 00:55:30 EDT Received: from kryten.aracnet.com (localhost [127.0.0.1]) by kryten.aracnet.com (8.8.5/8.8.5) with ESMTP id VAA02158 for ; Thu, 17 Jul 1997 21:58:57 -0700 Message-Id: <199707180458.VAA02158@kryten.aracnet.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Theodore Y. Ts'o" Subject: Re: Take A deep Breath In-Reply-To: Your message of "Thu, 17 Jul 1997 14:19:13 EDT." <199707171819.OAA20313@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 21:58:56 -0700 From: Tim Wright *** EOOH *** X-Mailer: exmh version 2.0gamma 1/27/96 To: "Theodore Y. Ts'o" Subject: Re: Take A deep Breath In-Reply-To: Your message of "Thu, 17 Jul 1997 14:19:13 EDT." <199707171819.OAA20313@dcl.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 21:58:56 -0700 From: Tim Wright re: Commercial code quality I couldn't agree more. One of the big (and pleasant) surprises working at Sequent was how well the source code (in particular the base OS kernel code) actually *is* documented both within the code and with accompanying design documentation. However, I have also had the "pleasure" of dealing with other third-party code (names deleted to protect the guilty) which makes the grubbiest parts of the Linux kernel look flawless by comparison. As you say, Andrew has a a very idealized view of the world :-) Regards, t -- Tim Wright | Aracnet -- Portland's loudest electrons timw@aracnet.com OR | Ring +1 503 626.6873 V.34 (28800) 24hrs timw@sequent.com | Browse http://www.aracnet.com for info! "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI  1,, Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA11855; Fri, 18 Jul 97 06:13:05 EDT Received: from [192.100.101.3] by MIT.EDU with SMTP id AA25865; Fri, 18 Jul 97 06:11:47 EDT Received: from hedera.bnr.co.uk (actually eharg1e1.nortel.co.uk) by eurogate.nortel.co.uk with SMTP (PP); Fri, 18 Jul 1997 10:12:49 +0000 Received: from bhars8cd.europe.nortel.com by hedera.bnr.co.uk with SMTP (PP); Fri, 18 Jul 1997 10:12:29 +0000 Received: from bharh4d4.europe.nortel.com by bhars8cd.europe.nortel.com (5.61++/UK-2.1-MX-nortel-(19970425)) with SMTP id AA11712; Fri, 18 Jul 97 11:12:16 +0100 Date: Fri, 18 Jul 1997 11:10:51 +0100 (BST) From: "Andy J. Smith" X-Sender: ajsmith@bharh4d4.europe.nortel.com To: "Theodore Y. Ts'o" Cc: "Andrew E. Mileski" , fygrave@freenet.bishkek.su Subject: Re: Take A deep Breath In-Reply-To: <199707171819.OAA20313@dcl.MIT.EDU> Message-Id: Organisation: Nortel Technology Ltd. Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII *** EOOH *** Date: Fri, 18 Jul 1997 11:10:51 +0100 (BST) From: "Andy J. Smith" X-Sender: ajsmith@bharh4d4.europe.nortel.com To: "Theodore Y. Ts'o" Cc: "Andrew E. Mileski" , fygrave@freenet.bishkek.su Subject: Re: Take A deep Breath In-Reply-To: <199707171819.OAA20313@dcl.MIT.EDU> Organisation: Nortel Technology Ltd. Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII [note, I've not posted this to linux-kernel since it is a bit off-topic] On Thu, 17 Jul 1997, Theodore Y. Ts'o wrote: > I've talked to a number of folks who have a spent a lot of time working > in such environments, and they've all told me that there's a lot of > unbelievable crap out there, in software which you may be using every > day. The issue is that in the "rush to market", there's often not time > to do full debugging and coding and internal documentational. This is very true. I myself have been working on a large project that ports to almost every Unix architecture you have heard of (even Linux, though sadly unofficially at present ;). There is code in there written by people who have left the company or are long forgotten. A lot of it is so unreadable that it takes a team of developers a month just to work out what it is trying to do. And yet we are not following poor coding standards or procedures - 2 months ago we underwent a strict inspection by the British Standards Institution, whose report said that they were extremely impressed with our procedures. This department spends hundreds of thousands of pounds every year on running and maintaining the ClearCase revision control system so we can attempt to keep track of all the code changes. Yet major problems (from our point of view, not necessarily the customer's) in key areas like threading and tasking are left as they are because we have a difficult choice: agree to give the customers what they want in a new version, or spend all our time prettying up code and fully understanding older code. > And after the code freeze deadline has been met, the next deadline, > with features that have already been promised to customers by the > salesmen, comes up so quickly there's often little time to clean up > after the short cuts that were made to meet the *last* code deadline. .. And I know the agony of testing and preparing a huge multi-platform product for customer use. I usually plan for six weeks after the code freeze to test the product, fix show-stopping bugs and deliver the thing to our web sites. > This is why being able to read poorly documented code is a very > important real world skill.... Compared to a lot of what I see every day, the kernel source is very readable. I don't actually do any development on the kernel, but I do like finding out how things work. I could get in trouble for saying this, but: There are 30 or so highly skilled Unix software engineers in this department, and the general feeling is that we are constantly pandering to the specialised needs of individual customers, rather than being given the time to develop the product how *we* want. Rarely is there time to fix things up before a new release with new features and new bugs is wanted. That's just the way it is. Kernel developers are lucky to have such a project that although it doesn't pay, is an enjoyable pursuit which they have a lot of personal control over. :) > P.S. I myself have seen various OS source code from various big-name > Unix manufacturers, and all I can say is that I have a fresh understanding > why many of said companies either (a) don't want to show the source code > to customers at all, and (b) want people who do look at the source code > to agree to sign a NDA where in some cases they aren't even allowed to > make any negative comments about the company...... And hence, I'll be inserting my standard disclaimer. ;-) Andy This message may contain information proprietary to Nortel Technology Ltd., so any unauthorised disclosure, copying or distribution of its contents is strictly prohibited.  1,, Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA13997; Fri, 18 Jul 97 07:10:48 EDT Received: from [208.205.20.18] by MIT.EDU with SMTP id AA29376; Fri, 18 Jul 97 07:09:30 EDT Received: from vger.rutgers.edu [128.6.190.2] (root) by i-m-f.org with esmtp (Exim 1.625 #1) id 0wpAvD-00024l-00 (Debian); Fri, 18 Jul 1997 04:10:03 -0700 Received: by vger.rutgers.edu id <970982-8840>; Fri, 18 Jul 1997 06:58:54 -0400 Received: from axl01it.ntc.nokia.com ([131.228.118.232] HELO axl01it.ntc.nokia.com ident: IDENT-NOT-QUERIED [port 35049]) by vger.rutgers.edu with SMTP id <971056-8840>; Fri, 18 Jul 1997 06:57:46 -0400 Received: from laurel.trs.ntc.nokia.com (laurel.trs.ntc.nokia.com [131.228.121.63]) by axl01it.ntc.nokia.com (8.6.9/8.6.9) with ESMTP id NAA06451; Fri, 18 Jul 1997 13:52:11 +0300 Received: by laurel.trs.ntc.nokia.com (1.37.109.16/16.2) id AA264533334; Fri, 18 Jul 1997 13:55:34 +0300 To: fizban@tin.it Cc: linux-kernel@vger.rutgers.edu Subject: Re: Take a deep breath... References: From: Kohtala Marko Date: 18 Jul 1997 13:55:34 +0300 In-Reply-To: Riccardo Facchetti's message of Thu, 17 Jul 1997 22:15:43 +0200 (MET DST) Message-Id: Lines: 43 X-Mailer: Gnus v5.3/Emacs 19.34 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk *** EOOH *** To: fizban@tin.it Cc: linux-kernel@vger.rutgers.edu Subject: Re: Take a deep breath... References: From: Kohtala Marko Date: 18 Jul 1997 13:55:34 +0300 In-Reply-To: Riccardo Facchetti's message of Thu, 17 Jul 1997 22:15:43 +0200 (MET DST) Lines: 43 X-Mailer: Gnus v5.3/Emacs 19.34 X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk Riccardo Facchetti writes: > On Thu, 17 Jul 1997, Raul Miller wrote: > > > A perverse fascination (and a long-term desire for speed) leaves me > > wondering how non-emacs users manage large scale browsing. > > Not really hard to do with vi, grep and heavy use of VTs. > Have you ever grep'ed something like 'grep foobar **/*.c' ? > After that, you have at least 10 VTs to edit the files. I have only seen quite awkward looking hits to how to browse a large source tree. Here is a list of tools that I use. These tend to be fast in finding the interesting lines and opening the file and taking to the line. - etags. Building of the database from Linux source takes a command like one below in linux source root find . -name '*.[chsS]' ! -name '*,*' | etags - Emacs has command M-. to move definitions of the word under cursor. Also, emacs has M-x tags-search command to search with regexp in all appearing in TAGS file. Many vi editors support tags made with ctags. - id-utils. Run command mkid without arguments in Linux source root. There is id-utils.el for emacs such that you can find all occurrences of a word under cursor in an instant in a grep like buffer in which you can say C-c C-c to go to the line you point to in the grep buffer, as well as other compile mode commands. Vi users could perhaps use the command line tools like lid for the same purpose. - find, xargs, grep. This is slow, but has more control over the files searched and more options for searching. Command goes like find . -name '*.[chsS]' | xargs grep -i 'what' If only i386 target is interesting, something like find . ./arch/i386 -follow -name asm-\* -prune -o -name arch -prune -o -name '*.[chsS] -print is a better find command. There is an emacs package for this kind of finds called igrep. Should be available in elisp archives. -- --- Marko Kohtala - Marko.Kohtala@ntc.nokia.com, Marko.Kohtala@hut.fi  1,, Received: from SOUTH-STATION-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA07853; Fri, 18 Jul 97 04:04:08 EDT Received: from [137.44.4.77] by MIT.EDU with SMTP id AA02643; Fri, 18 Jul 97 04:04:06 EDT Received: from lightning.swansea.linux.org.uk (surd [137.44.10.205]) by swan.ml.org (8.7.4/8.7.3) with SMTP id JAA04636 for ; Fri, 18 Jul 1997 09:03:49 +0100 Received: by lightning.swansea.linux.org.uk (Smail3.1.29.1 #2) id m0wp8tK-0005FiC; Fri, 18 Jul 97 09:59 BST Message-Id: From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: Take A deep Breath To: tytso@MIT.EDU (Theodore Y. Ts'o) Date: Fri, 18 Jul 1997 09:59:58 +0100 (BST) In-Reply-To: <199707180244.WAA27663@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Jul 17, 97 10:44:07 pm Content-Type: text *** EOOH *** From: alan@lxorguk.ukuu.org.uk (Alan Cox) Subject: Re: Take A deep Breath To: tytso@MIT.EDU (Theodore Y. Ts'o) Date: Fri, 18 Jul 1997 09:59:58 +0100 (BST) In-Reply-To: <199707180244.WAA27663@dcl.MIT.EDU> from "Theodore Y. Ts'o" at Jul 17, 97 10:44:07 pm Content-Type: text > relationship to the Microsoft/Netscape world, where companies release > barely tested BETA code in order to beat the other in the browser wars, > for example. Sure 8) Ted you've obviously not seen things like the 911 system written in visual basic or the UK police who in mid 1997 realised their prehistoric OS was going to go blam in 2000 ;) Alan  1,, Received: from PACIFIC-CARRIER-ANNEX.MIT.EDU by po9.MIT.EDU (5.61/4.7) id AA26687; Tue, 22 Jul 97 11:17:30 EDT Received: from DCL.MIT.EDU by MIT.EDU with SMTP id AA17671; Tue, 22 Jul 97 11:16:10 EDT Received: by dcl.MIT.EDU (SMI-8.6/4.7) id LAA17741; Tue, 22 Jul 1997 11:17:15 -0400 Date: Tue, 22 Jul 1997 11:17:15 -0400 Message-Id: <199707221517.LAA17741@dcl.MIT.EDU> From: "Theodore Y. Ts'o" To: scottr@wwa.com Cc: hamilton@pobox.com, linux-kernel@vger.rutgers.edu In-Reply-To: Randy D. Scott's message of Mon, 21 Jul 1997 21:13:16 -0500 (CDT), Subject: Re: kernel documentation is bad Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 *** EOOH *** Date: Tue, 22 Jul 1997 11:17:15 -0400 From: "Theodore Y. Ts'o" To: scottr@wwa.com Cc: hamilton@pobox.com, linux-kernel@vger.rutgers.edu In-Reply-To: Randy D. Scott's message of Mon, 21 Jul 1997 21:13:16 -0500 (CDT), Subject: Re: kernel documentation is bad Address: 1 Amherst St., Cambridge, MA 02139 Phone: (617) 253-8091 Randy, A lot of people have made some very sweeping statements about "the needs of the developers". What is best for any particular developer really depends on what sort of style they have. For example, I am very adept at reading and analyzing source code. It took me at most 15-20 minutes to figure out Linus's new dcache abstraction. I doubt the documentation would have speed up this learning curve by much; the interface was clean and didn't have many surprises, and I can read C just as quickly as I can read English. I am sure that it would have taken Linus more than 15-20 minutes to document the dache abstraction. Hence, your assertion that documentation always helps just simply isn't true --- all the time. A certain amount of documentation is good, sure. And I try to make sure that the general interfaces that I write do have documentation. However, much, much more important that documentation is a clean design. If the design is clean, then the code is effectively self-documenting to someone who knows what they are doing. I fault the "Software Engineering" college courses that are so popular these days precisely because they make people overly dependent on documentation. In the real world, documentation is rarely 100% up to date. Hence, being able to read source code is essential. Unfortunately, I have seen far, far, far too many programmers who (a) are completely, 100% helpless without formal documentation, and (b) couldn't design a clean abstraction to save their life. I actually believe the two are related --- see my previous posting about "thinking at multiple levels of abstraction", and how you need to be able to do that in order to read and understand code. Finally, if you want to pursuade kernel developers to better document the kernel, I suggest you try an approach of thanking them and encouraging those who do document their code and their interfaces, instead of shaking your figures at them and complaining about how they aren't following good software engineering practice. After all, those developers have created a wildly successful OS from nothing; you might want to give them credit for having *some* skills. - Ted