The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

linux-kernel FAQ (1/2)


<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
 From : Boris Tobotras                      2:5020/510      30 Jun 97  21:06:00 
 Subj : linux-kernel FAQ (1/2)                                                  
________________________________________________________________________________
Newsgroups: RU.LINUX
Subject: linux-kernel FAQ
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII


   [1]
   
                             $Revision: 1.20 $
                                      
                                   CONTENTS
                                       
   [2]0. Introduction
   [3]1. The kernel mailing list
   [4]1.1. How do I get off of this mailing list ???
   [5]1.2. Topic
   [6]1.3. Off-topic
   [7]1.4. Etiquette
   [8]1.4.1. Questions
   [9]1.4.2. Answers
   [10]1.5. Bug Reports
   [11]1.6. Kernel patches
   [12]1.7. Be ready to get spammed
   [13]2. On- and off-line resources
   [14]2.1. Kernel resources
   [15]2.1.1. The Linux Kernel HOWTO - How to compile a kernel
   [16]2.1.2. Linux v2 Information HQ
   [17]2.1.3. The kernel hackers guide
   [18]2.1.4 LXR
   [19]2.1.5 Mailing lists
   [20]2.1.6. Writing device drivers
   [21]2.1.7. The Linux Wish List
   [22]2.1.8. Periodicals
   [23]2.1.9. Books
   [24]2.1.10. Classes
   [25]2.2. Other points of interest
   [26]2.2.1. The Linux Home Page
   [27]2.2.2. The Linux documentation project
   [28]2.2.3. The Linux Software Map
   [29]2.2.4. IRC
   [30]2.2.5. Linux news groups
   [31]2.2.6. Linux Gazette
   [32]2.2.7. Other URLs
   [33]3. The kernel
   [34]3.1. Common problems
   [35]3.1.1. What do I need to do to make to activate a kernel feature?
   [36]3.1.2. Before you dive into it
   [37]3.1.3. File system corruption
   [38]3.1.4. Signal 11
   [39]3.1.5. Seasonal Problems
   [40]3.1.5.1. Warning: possible SYN flooding. Sending cookies.
   [41]3.1.5.2. Kernel hangs after "Now booting the kernel ..."
   [42]3.1.5.3. Ignoring P6 Local APIC Spurious Interrupt Bug
   [43]3.1.5.4. nfs warning: mount version older than kernel
   [44]3.1.5.5. Objdump problems ... can't compile a zImage
   [45]3.1.5.6. New kernels block in the fcntl() call
   [46]3.1.5.7. Sockets getting stuck in close()
   [47]3.1.5.8. AMD K6 fails at high clock rates
   [48]3.1.5.9. Less than 4MB RAM
   [49]3.1.5.10. Martian Packets
   [50]3.2. Is there ... ?
   [51]3.2.1 ... an encrypted file system?
   [52]3.2.2 ... a kernel suitable for embedding?
   [53]3.2.3 ... a kernel regression test suite?
   [54]3.2.4. ... a decent auto mounter?
   [55]3.2.5. ... an ACL implementation?
   [56]3.2.6. ... a better numbering scheme for SCSI devices?
   [57]3.2.7. ... a lofs?
   [58]3.2.8. ... Sys V TLI for Linux?
   [59]3.2.9. ... a patch that allows for more IP aliases?
   [60]3.3. Kernel development
   [61]3.3.1. Tips
   [62]3.3.1.1. How to find your way around the kernel
   [63]3.3.2. How to get started
   [64]A. Appendix A - Maintainers
   [65]B. Appendix B - Linux Kernel Mailing List Bug Report Form
   [66]C. Appendix C - Unresolved Issues
   [67]D. Appendix D - Change Log
     _________________________________________________________________
   
                                0. Introduction
                                       
   This is the Linux kernel mailing list FAQ and usage policy. It was
   intended to be posted to the mailing list regulary. Due to its size,
   only section 1 will be posted to the list, the other part is available
   on the World Wide Web on [68]<URL:http://kernelfaq.iconsult.com>;. An
   older version of this FAQ will be sent to new subscribers of the
   kernel mailing list.
   
   The first section contains information about the kernel mailing list.
   Please read it before posting to the list to make sure you're using
   everyone's time in the most efficient manner.
   
   The FAQ is currently being reworked, the first step being a rough
   translation from formatted ASCII to HTML. I'm also considering
   following the necessary steps to make it an official USENET FAQ, being
   posted to comp.os.linux.answers and the other appropriate *.answers
   groups regulary.
   
   I'm sorry for not posting the document to the mailing list in june, I
   didn't want to post the full 60k document anymore and my 'real world'
   work kept me from making an updated version.
   
                          1. The kernel mailing list
                                       
1.1. How do I get off of this mailing list ???

   Send mail containing "unsubscribe linux-kernel" (without the quote
   marks) in the body of the message (not the subject line) to
   majordomo@vger.rutgers.edu.
   
    (echo "unsubscribe linux-kernel" | mail majordomo@vger.rutgers.edu)

   If that doesn't work you probably are subscribed using another email
   address than the one you're using now. In that case the first thing to
   do is to find out the email address you subscribed with. (You're on
   your own here, but your system administrator might help you by
   checking the mail transfer agent's log files)
   
   When you found out the address use:
   
    (echo "unsubscribe linux-kernel" "the address you subscribed with"
                                 | mail majordomo@vger.rutgers.edu)

   By the way, a small tip for mailing lists in general: On some mailing
   lists the "unsubscribe <list> <address>" syntax doesn't work. In that
   case use Netscape Navigator to send a mail with faked sender address:
   Enter your "address you subscribed with" in Netscape's "Options/Mail
   and News preferences/Your Email" field, fill in your current address
   in the "Reply-to Address" and send the unsubscribe mail from Netscape.
   Normally the mailing list software will believe the faked "From:"
   field in the mail.
   
1.2. Topic

   This list discusses Linux kernel development. All submissions relevant
   to that, such as bug reports, enhancement ideas, kernel patches or
   reports that a patch fixed a bug are appropriate. Please note the
   emphasis on kernel development as opposed to development of Linux
   systems in general.
   
1.3. Off-topic

   Please do not ask basic installation or non-kernel related
   configuration questions on this list. If you are unclear of the
   distinction between the Linux kernel and other parts of a Linux
   system, please do not post here until you have learned somewhere else;
   just have a look at the Linux resources in Section 2 of this document.
   In particular, if you don't know the difference between XFree86 and
   the Linux kernel, please do not ask about it here. (If you don't know
   what I'm talking about, this means you.)
   
1.4. Etiquette

   As Linux grows in popularity, it is inevitable that subscriptions to
   the list will greatly increase. The list is already quite large and
   beginning to suffer from the classic Usenet signal to noise ratio
   problem. Reading the list daily gives a sense of involvement and
   excitement at being so close to the cutting edge of a compelling and
   rapidly evolving technology. It is important to note that your post
   will go out to many, many people and that "send" key is so very
   close... A good idea to consider: "My opinions really don't matter,
   but my _code_ most certainly does!" Please help us to prove that this
   list can scale well to such a large audience.
   
  1.4.1. Questions
  
   Before posting a question to this list, think twice about whether it
   is indeed kernel-related. Perhaps another newsgroup or mailing list is
   better suited for the question. See Section 2 for a list of on-line
   resources.
   
   In any event have a quick look at the Documentation/Changes file, and
   ensure that your software is up-to-date. Sometimes things change
   within the kernel which stop user-level code from working. You'll feel
   a little silly if the answer to the problem is in the documentation
   that comes with the kernel, but you just didn't read it.
   
   A good strategy is to wait a day after writing something before
   posting. The very same information may hit the list during that time,
   especially if the problem you are experiencing is one which many
   people will find (e.g., "ps and top have stopped working!"). Probably
   someone else will ask about it too; there's nothing more annoying than
   seeing the same question on the list over and over again.
   
  1.4.2. Answers
  
   Before posting an answer to this list, also think twice! When
   off-topic mail arrives (e.g., "I can't build the kernel", "how do I
   convert ASCII to EBCDIC" or "Make money fast"), it is best to answer
   directly (i.e., off this list). Despite our best efforts, these
   questions will always appear; there is no easy way to avoid this
   without moving away from creative anarchy. Dumb questions are at least
   a positive sign of usage and growth. We all hate spam, but flaming to
   the list just makes it worse.
   
   Before you post an answer to a legitimate question, think twice again.
   If possible try to give an answer that might help more people than the
   original poster. For example posting generic strategies helps a lot of
   people (especially newbies). Some great examples of such posts by
   Cameron McKinnon (how to get started) and Doug Ledford (on extfs
   problems) have ended up in this document.
   
   I know all those 'think twice' are more easily said than done, but
   remember _everyone_ that even tries to think will make the kernel
   mailing list a more enjoyable place for all.
   
   "Most people think about twice a year. I got famous by thinking once a
   week." - George B. Shaw (see Appendix A)
   
1.5. Bug Reports

   There are a few things to consider before reporting kernel error
   messages:
   
  Try to have a clue
  
   A good rule of thumb that applies to everything in life - even to
   linux kernel development. Think of things that might be of interest to
   the developers, things that are redundant. Find out how other people's
   report bugs look and what the reaction in the list is.
   
  The developers don't have access to your system.
  
   This means they don't have much information on how your kernel was
   built, which addresses certain routines were compiled to or which
   hardware you run. To get a rough idea what information might be
   relevant to the developers read the following paragraphs, then have a
   look at the bug report form and data collection shell script in
   Appendix B.
   
   The most complicated thing to do is to add symbolic information to
   your kernel error message. Once (back in the good old days) this was
   quite an ordeal, but with modern klogd/syslogd install this gets quite
   easy. Make sure your kernel's System.map is installed in the right
   place (/boot/System.map, /System.map or /usr/src/linux/System.map) and
   from now on klogd will automatically add symbolic information to the
   kernel messages it logs. See 'man klogd' to check whether the version
   of klogd you run does already support that feature.
   
   For similar functionality look at the ksymoops program in the kernel
   source tree, which can be used when klogd/syslogd logged a 'raw'
   kernel Oops.. message to your disk (or if you copied it down by hand,
   because the system froze before being able to write to the hard disk.)
   
   When symbolic information is added to the report you'll have to
   provide everything else relevant to the problem. A general rule of
   thumb is: Too much information won't hurt, not enough will. Be sure to
   include at least some general description of your hardware like
   processor, RAM, how many and what kind of disks, disk controllers
   (IDE? SCSI?) and expansion board. In particular, make sure you mention
   which kernel you are trying to use. Use the bug report form and data
   collection shell script from Appendix B.
   
   If you feel you should include your .config file, please send the
   output of "grep '^[^#]' .config" instead of the whole thing, as this
   saves a lot of wasted space.
   
  The developers are busy developing
  
   Often the developers are so busy developing, they will read your mail
   but not have the time to answer it. While you might say 'it does not
   take much time to answer an email' you might overlook the fact that

 * Message split, to be continued *
--- Gnus v5.4.37/XEmacs 19.15
 * Origin: Linux inside (2:5020/510@fidonet)

_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
 From : Boris Tobotras                      2:5020/510      30 Jun 97  21:06:00 
 Subj : [part 2] linux-kernel FAQ (1/2)                                         
________________________________________________________________________________
 * Continuation 1 of a split message *

   developers often get flooded with email, so much that they get
   nightmares about it. Answering an email does in fact not take much
   time, answering 100 emails does.
   
  Trying to help the developers makes the bug vanish faster ...
  
   If you like to be of great help to the developers you might find out
   if other people have the same problem. Finding the general patterns of
   a bug is a job that does not take months, and it is a job that you can
   perform if you have never seen a single line of C source.
   
   Try to find some conditions that reliably trigger the problem, this
   includes asking other people if they have similar problems. If yes,
   which hard- and software do they use? For example you might find out
   your ext2fs file system errors are limited to users of the brand xyz
   SCSI controller Mark 42. _Such_ a result will alert the developer of
   the xyz SCSI driver, while a message like 'My ext2fs got bad! Linux
   sucks!' probably won't.
   
  Try to reach the appropriate people.
  
   Sometimes it is better to communicate to the developers directly by
   email instead of posting to the mailing list. See the MAINTAINERS file
   in the Linux source tree to find out the maintainer for a specific
   Linux subsystem. In addition, there are a number of mailing lists for
   specific parts of the kernel (e.g. scsi, net, etc.); you might want to
   join those lists as well, since that is where the experts hang out.
   
1.6. Kernel patches

   A little bit of consideration first: If possible create patches that
   change _one_ thing in the kernel. Doing so enables people to choose
   which part of your changes they use (or even include in the
   distribution kernel.) While your SCSI driver fixes might be perfectly
   sane, people might not like your change to the network layers changing
   network addresses from being big-endian to little-endian.
   
   Always use unified (-u) diff format when submitting kernel patches.
   The unified diff format is very readable and allows 'reverse'
   application for undoing a patch (which is extremely useful when the
   patch provider 'diffed' the sources the wrong way round). Oh, and
   don't uuencode patches, but keep them in textual format that is
   readable right there in the messages. If the patch is real big then
   post the URL of the patch.
   
   Assuming you have two source trees of the _same_ version of Linux, an
   original one {original-source-tree} and one with your personal changes
   {your-source-tree}, the recommended procedure for creating patch files
   is:
   
    $ make -C {original-source-tree} distclean
    $ make -C {your-source-tree} distclean
    $ diff -urN {original-source-tree} {your-source-tree} >/tmp/linux-patch

   The patch file will then be in /tmp/linux-patch waiting to be deployed
   on the Linux kernel mailing list. When posting your patch, don't
   forget to mention what it does.
   
   Of course you need to set up two identical source directories to be
   able to diff the tree later. A nice trick -- it requires a little bit
   of consideration, though -- is to create the 'your-source-tree' from
   hard links to the 'original-source-tree':
   
    $ tar xzvf linux-2.1.anything.tar.gz
    $ mv linux linux-2.1.anything.orig
    $ cp -av --link linux-2.1.anything.orig linux-2.1.anything

   This will hardlink every source file from the original tree to a new
   location; it is very fast, since it does not need to create more than
   20 megabytes of files.
   
   You can now apply patches to the linux-2.1.anything source tree, since
   patch does not change the original files but move them to
   <filename>.orig, so the contents of the hard-linked file will not be
   changed.
   
   Assuming that your editor does the same thing, too (moving original
   files to backup files before writing out changed ones) you can freely
   edit within the hardlinked tree.
   
   Now the changed tree can be diffed at high speed, since most files
   don't just have identical contents, they are identical files in both
   trees. Naturally removing that tree is quite fast, too.
   
   Thanks to Janos Farkas <URL:mailto:chexum@shadow.banki.hu> for that
   trick.
   
1.7. Be ready to get spammed

   Some "nice guys" are obviously monitoring the kernel mailing list to
   get email addresses. Every time I post to the mailing list I get a
   bunch of "Earn $800 a week extra income" mails. Be ready to ignore or
   handle this (maybe using procmail).
   
- --- cut here for mailing list version ---

                         2. On- and off-line resources
                                       
   If you think something should be listed here, please send an e-mail to
   the current list maintainer ([69]<URL:mailto:kernelfaq@iconsult.com>).
   Resources will be listed in "URL embedded in text file" syntax to ease
   transition to these resources.
   
2.1. Kernel resources

  2.1.1. The Linux Kernel HOWTO - How to compile a kernel
  
   You definitely ought to look at this unless you can cite every line of
   the kernel Makefile from memory.
   
   This document describes how to obtain, unpack, compile and install a
   new kernel and shows some of the pitfalls that lurk on the road of
   upgrading.
   
   [70]<URL:http://www.caldera.com/LDP/Kernel-HOWTO.html>;
   [71]<URL:http://sunsite.unc.edu/LDP/Kernel-HOWTO.html>;
   
   If you are looking for all the other HOWTOS and mini-HOWTOS just check
   out LDP itself:
   
   [72]<URL:http://www.caldera.com/LDP/>;
   [73]<URL:http://sunsite.unc-edu/LDP/>;
   
  2.1.2. Linux v2 Information HQ
  
   [74]<URL:http://www.linuxhq.com>;
   
   A very useful site that lists Linux V2 information including, but not
   limited to, "what's new", "how to upgrade", source code, official and
   unofficial kernel patches for V2.0 and V2.1 and archives of the Linux
   mailing lists. Two thumbs up.
   
   Please note that the old URL [75]<URL:http://www.ecsnet.com>; for now
   is deprecated, so please update your bookmarks to reflect the new
   location.
   
  2.1.3. The kernel hackers guide
  
   [76]<URL:http://www.redhat.com:8080/HyperNews/get/khg.html>
   
   Once upon a time it was a paper document but due to the 'moving
   target' nature of a constantly developed kernel it is now completely
   web-based, using a hyper-news system so users can add input.
   
  2.1.4 LXR
  
   [77]<URL:http://lxr.linux.no>;
   
   LXR is the application of a cross reference tool currently being
   developed to the Linux kernel source. The main features are:
   
     * Comprehensive cross-indexing
     * Freetext search (using glimpse)
     * Support for multiple versions/architectures
     * On-the-fly diff-generation
     * Updated sources
       
  2.1.5 Mailing lists
  
   As mentioned above, there are a number of more specialized Linux
   mailing lists. Many of these are run from vger.rutgers.edu. To get a
   listing of those running at vger, send an e-mail to
   [78]<URL:mailto:majordomo@vger.rutgers.edu>, containing the single
   word "lists". Some of the lists are mentioned in the MAINTAINERS file
   in the Linux source code.
   
   A lot of mailing lists are archived at the Linux v2 Information HQ
   [79]<URL:http://www.linuxhq.com/lnxlists>;.
   
   Having a close look at the linux-admin list would be worth-wile. Many
   of the off-topic questions on linux-kernel are appropriate for
   linux-admin and the latter list seems to be pretty well behaved. The
   admin list is approaching the amount of traffic on the kernel list.
   
  2.1.6. Writing device drivers
  
   [80]<URL:http://www.redhat.com/~johnsonm/devices.html>;
   
   A paper of a talk by Michael K. Johnson given at Spring DECUS'95.
   According to the author this is probably a bit dated but might be
   still worth reading.
   
  2.1.7. The Linux Wish List
  
   [81]<URL:http://www.cs.uml.edu/~acahalan/linux/wishlist.html>;
   
   The Linux Wish List, compiled from the contents of the kernel mailing
   list. Check this before posting enhancement requests to the mailing
   list or to get some inspiration for your kernel project.
   
  2.1.8. Periodicals
  
    Linux Journal
    
   [82]<URL:http://www.ssc.com/lj/>;
   
   Linux Journal has had a long-running series of articles called Kernel
   Korner which, has had quite a bit useful information in it. Four
   articles on writing runtime-loadable character device drivers in
   issues 23 - 26 have been made available on Linux Journal's WWW Site:
   
   [83]<URL:http://www.ssc.com/lj/issue23/1219.html>;
   [84]<URL:http://www.ssc.com/lj/issue24/kk24.html>;
   [85]<URL:http://www.ssc.com/lj/issue25/kk25.html>;
   [86]<URL:http://www.ssc.com/lj/issue26/interrupt.html>;
   
  2.1.9. Books
  
   There aren't any book reviews in this section, just pointers to those.
   First you might want to look at Cameron McKinnon's article on getting
   started with kernel development, which also mentions some books.
   
   The next place to stop is the Linux Reading List Mini-HOWTO, which
   although being a bit dated list a lot of the books useful to kernel
   programmers:
   
   [87]<URL:http://www.caldera.com/LDP/HOWTO/mini/Reading-List>;
   [88]<URL:http://sunsite.unc.edu/LDP/HOWTO/mini/Reading-List>;
   
   Cameron McKinnon's Article mentions 'The Magic Garden Explained',
       here's some more information about it:
       Author: Goodheart, Berny
       Full Title: The Magic Garden Explained, the internal of UNIX
       System V Release 4, an open system design, Berny Goodheart and
       James Cox
       Publisher: Prentice-Hall (New York)
       Released: 1994
       Programmation Linux 2.0 - API systeme et fonctionnement du noyau
       de Remy Card, Eric Dumas et Franck Mevel Editions Eyrolles
       It was mentioned this is a very good book, unfortunatley it is not
       available in english. It discusses all the kernel behaviour and
       structures (based on 2.0.X) with many bits of sources. It
       discusses the API system, too.
       Linux Kernel Internals, by Beck, Bohme, Dziadzka, Kunitz, Magnua
       and Verworner, Addison-Wesley
       ISBN: 0-201-87741-4.
       This one is more a description of the kernel internals. It makes
       some assumptions about what you already know about OSes. It
       requires some experience with C.
       Inside Linux, by Bentson, SSC, ISBN: 0-916151-89-1
       This one is a lot less technical, but does not assume as much
       previous knowledge
       
  2.1.10. Classes
  
   This class teaches TCP and web server internals using the Linux kernel
   and the Apache web server. I thought it was neat, and the set of
   references are rather interesting in particular if you are interested
   in research that has been done on web server performance.
   
   [89]<URL:http://www.cs.bu.edu/faculty/djy/cs835-fall96.html>;
   
   Answered by David S. Miller [90]<URL:mailto:davem@jenolan.rutgers.edu>
   
2.2. Other points of interest

  2.2.1. The Linux Home Page
  
   [91]<URL:http://www.linux.org>;
   
   A very good starting point for the new and old Linux user. It contains
   many starting points including information on the history and creation
   of Linux, FAQ's and HOWTOs, Linux Software Map, Manual Pages, Usenet
   Newsgroups, Where To Get Linux, Linux Documentation Map, Linux
   International, Linux On The World Wide Web, Hot Linux News, Linux
   Gazette, and Linux Journal.
   
  2.2.2. The Linux documentation project
  
   The Linux documentation project:
   
   [92]<URL:http://www.caldera.com/LDP>;
   [93]<URL:http://sunsite.unc.edu/LDP>;
   
   The LDP contains _loads_ of Linux documentation, including, but not
   limited to the HOWTOS, FAQs, man pages and various guides.
   
  2.2.3. The Linux Software Map
  
   There are a few different web frontends for the Linux Software Map:
   
   [94]<URL:http://www.ssc.com/linux/lsm.html>;
   [95]<URL:http://www.ngs.fi/lsm>;
   [96]<URL:http://www.boutell.com/lsm>;
   
   If you prefer downloading the whole database and browsing it offline
   get it at:
   
   [97]<URL:ftp://ftp.execpc.com/pub/lsm/>;
   
  2.2.4. IRC
  
   There is said to be online support on IRC, namely servers
   irc.linpeople.org (207.16.36.11) or vinge.linpeople.org. Look for the
   channels #help or #natter.
   
   An IRC client is required to connect to the many IRC networks

 * Message split, to be continued *
--- Gnus v5.4.37/XEmacs 19.15
 * Origin: Linux inside (2:5020/510@fidonet)

_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
 From : Boris Tobotras                      2:5020/510      30 Jun 97  21:06:00 
 Subj : [part 3] linux-kernel FAQ (1/2)                                         
________________________________________________________________________________
 * Continuation 2 of a split message *

   available on the Internet. A good place to find IRC clients is:
   
   [98]<URL:ftp://cs-pub.bu.edu/pub/irc/clients>;
   
  2.2.5. Linux news groups
  
     * [99]<URL:news:comp.os.linux.advocacy>
       Benefits of Linux compared to other operating systems
     * [100]<URL:news:comp.os.linux.announce>
       Announcements important to the Linux community. (Moderated)
     * [101]<URL:news:comp.os.linux.answers>
       FAQs, HOWTOs, READMEs, etc. about Linux. (Moderated)
     * [102]<URL:news:comp.os.linux.development.apps>
       Writing Linux applications, porting to Linux
     * [103]<URL:news:comp.os.linux.development.system>
       Linux kernels, device drivers, modules
     * [104]<URL:news:comp.os.linux.hardware>
       Hardware compatibility with the Linux operating system
     * [105]<URL:news:comp.os.linux.m68k>
       Linux operating system on 680x0 Amiga, Atari, VME
     * [106]<URL:news:comp.os.linux.misc>
       Linux-specific topics not covered by other groups
     * [107]<URL:news:comp.os.linux.networking>
       Networking and communications under Linux
     * [108]<URL:news:comp.os.linux.setup>
       Linux installation and system administration
     * [109]<URL:news:comp.os.linux.x>
       Linux X Window System servers, clients, libs and fonts
       
  2.2.6. Linux Gazette
  
   [110]<URL:http://www.ssc.com/lg>;
   
   The Linux Gazette is a monthly compilation of basic tips, tricks,
   suggestions, ideas, and short articles about Linux designed to make
   using Linux fun and easy. LG began as a personal project of John M.
   Fisk, and grew to include contributions freely provided by a growing
   number of authors.
   
  2.2.7. Other URLs
  
     * Linux kernel
       [111]<URL:ftp://ftp.cs.helsinki.fi/pub/Software/Linux/Kernel/>;
     * Linux on the web [112]<URL:http://www.ssc.com/linux/web.html>;
     * Sunsite Linux archive [113]<URL:http://sunsite.unc.edu/pub/Linux/>;
     * Find new files on Sunsite
       [114]<URL:http://sunsite.unc.edu/paulc/incoming.html>;
     * Linux kernel change summary
       [115]<URL:http://www.crynwr.com/kchanges/>;
     * Linux Source Navigator
       [116]<URL:http://sunsite.unc.edu/linux-source>;
     * Linux archive search [117]<URL:http://torgo.ml.org/las>;
     * Linux network drivers
       [118]<URL:http://cesdis1.gsfc.nasa.gov:80/linux/drivers/>
     * Linux SMP project
       [119]<URL:http://www.uk.linux.org/SMP/title.html>;
     * Linux NOW! [120]<URL:http://www.linuxnow.com>;
     * Linux applications and utilities page
       [121]<URL:http://www.xnet.com/~blatura/linapps.shtml>;
     * Woven goods for linux - a collection of WWW applications and
       hypertext-based information about Linux.
       [122]<URL:http://www.fokus.gmd.de/linux>;
       
                                 3. The kernel
                                       
3.1. Common problems

  3.1.1. What do I need to do to make to activate a kernel feature?
  
   This is a quite frequent question, but one that is quite easily
   answered: Typically such features will be listed in the Changes file
   or elsewhere in the Documentation directory. If not documented there,
   the feature probably is in early stages of development (or old and
   badly maintained) so it is not suitable for public consumption. In the
   latter case look at the source, the the Maintainers file or the
   Resources Section of this document, since many brand new kernel
   features have specialized discussion forums.
   
  3.1.2. Before you dive into it
  
   Read up on all strategies for error recovery. Your file system
   corruption might be caused by the same problem that causes another
   user's Signal 11 trouble; a kernel is a complex piece of software, and
   errors happening in the kernel or in hardware below might cause every
   thinkable and unthinkable kind of problem. Errors propagate in
   unforseeable ways. There are hardware problems which show up only on
   Linux while Win95, NT, OS/2, Doom and Quake run fine on the same
   computer. You are dealing with software handling hardware, this is
   extremely complex and right next to black magic. Flipping one bit of
   memory in the kernel creates strange results, just like adding a drop
   of tabasco sauce to a witches cauldron might make her conjure up a
   horde of croaking frogs instead of the (by her) desired white prince.
   
  3.1.3. File system corruption
  
   "On a block device (block size 1024 bytes) with ext2fs, I don't
   reliably get back from a file what I first wrote in."
   
   Normally any kind of file system corruption is a sign of hardware
   problems or problems with a low level I/O driver. Ext2fs is a quite
   tested and stable file system, but due to its high performance it is
   likely to dig out problems in the lower levels of the system.
   
   When I experienced ext2fs file system corruption myself, a query on
   the linux newsgroups showed others had experienced similar problems.
   It turned out to be a firmware problem in the Conner CFP1060S hard
   drive, when data was read _really fast_ the buffer cache algorithm in
   the drive firmware failed.
   
   There are a lot of things to try when you get ext2fs corruption:
   
    tune2fs
    
   Use tune2fs to set your file system to drop into read only mode when
   an error occurs. This will prevent small errors causing catastrophes.
   The command is:
   
      tune2fs -e remount-ro /dev/???

   You should also use that command to set a time interval between file
   systems checks, because (especially on long running servers) it can
   take eons to reach the maximum mount count.
   
    Check the partition tables
    
   Especially on the Intel x86 platform partition tables can easily be
   broken. Such a problem can occur when the drives were partitioned
   using another disk controller than they are used with. Use fdisk dump
   the tables and ensure partitions are set up correctly.
   
    System tuning
    
   Tune Linux and your BIOS to slow and safe parameters. Turn off bus
   (PCI) optimizations.
   
    Search for the point of failure
    
   Use an empty partition to check if the problem lurks in the kernel
   levels below the file system. Probably the most simple test is to copy
   /dev/zero to the partition (using dd) and comparing the partition and
   /dev/zero afterwards (using cmp) if there are any differences.
   
   A very thorough test has been suggested on the mailing list by Doug
   Ledford [123]<URL:mailto:dledfor@dialnet.net>:
   
   "I'll go one step further with this. I would recommend that the people
   having problems with ext2fs corruption run the following test (if
   possible):
   
   Let's say you have a hard drive partition of decent size that you
   don't mind losing the data on (or even if you do mind, this test can
   turn up a lot of errors so if you have an inconvenient way of getting
   back, then you should probably do this anyway)
   
   First, get the exact size of the partition (or the whole drive as the
   case may be in some circumstances) in 1K blocks.
   
   Divide this total number of blocks into 4 equal chunks (most drives do
   this easily, some may have a few odd sized chunks).
   
   Write a script like this:
   
        badblocks -w -s -b 1024 -o /tmp/list.1 /dev/??? (blocks * .25) 0 &
        badblocks -w -s -b 1024 -o /tmp/list.2 /dev/??? (blocks * .5) (blocks *
 .25) &
        badblocks -w -s -b 1024 -o /tmp/list.3 /dev/??? (blocks * .75) (blocks
* .5) &
        badblocks -w -s -b 1024 -o /tmp/list.4 /dev/??? (blocks) (blocks * .75)
 &

   A simple shell script like this will run four simultaneous badblocks
   programs on the drive. A person can then check the files in the /tmp
   directory to see if any were returned as bad. With modern IDE or SCSI
   drives, all of these files should have a zero length unless one of two
   things is true. One, you have a drive developing too many bad sectors
   to be mapped out (which is cause for alarm in itself) or two, you have
   corruption in your low level driver (or other low level hardware such
   as memory or cache or bus transfer problems). If these test return all
   0 length files, then we should start looking elsewhere for the
   problem. Run the test several times, as a single pass may not show the
   problem. If you are really courageous, you can try doubling the tests
   by splitting the drive into 8 equal chunks (or if you have two drives
   you can do both drives at four chunks each at the same time). This is
   a standard test I use with the aic7xxx driver to find problems with
   tagged queueing and high commands per lun values. It seems to show
   problems much quicker than any file system activity would (in my case,
   I had as many as 24 of these running simultaneously on 6 drives in
   order to test this out, talk about a dog slow machine, it took about 5
   minutes just to start X windows under this load).
   
   In any case, running tests like these to rule out hardware corruption
   would help greatly in increasing the level of confidence that somehow
   the ext2fs layer is at fault (which I personally don't think it is
   except under very rare occasions since I have a hard hit news server
   running that file system without problems, but I've taken the care and
   gone to the lengths to run these tests on the particular hardware in
   that machine and identified bad combinations that can cause problems
   and worked around them at the driver level)."
   
   Later on Doug followed up to another article on the ext2fs corruption
   thread:
   
   "Correct. And it's very useful information to have at that. If you can
   produce corruption problems without going through the ext2fs code,
   then you have hardware corruption of some sort. An example of some of
   the things in the past that I have personally seen cause hardware
   corruption which made one *THINK* that something was wrong with the
   ext2fs code when there wasn't:
   
    1. Bad CPU fans on pentium and high speed 486 machines
    2. Bad SCSI cables
    3. Memory timing settings in BIOS being just a tad too aggressive
    4. Bad memory
    5. Bad Pipeline Burst (or other) cache
    6. Too long of a SCSI or IDE cable
    7. Interference between SCSI and IDE cables running in close
       proximity to each other
    8. Flaky CPU (had been overclocked and partially burnt out)
    9. Esoteric BIOS options being enabled when they shouldn't be (this
       takes some experimentation to find and fix, a change BIOS
       settings, test to see if problem is gone, if not, reboot and
       change settings again type thing)
       
   These are a few examples. A second thing to keep in mind is that the
   ext2fs is a rather fast filesystem by unix standards (it beats the
   hell out of the EAFS HTFS DTFS etc filesystems from SCO, but who's
   comparing SCO to linux anyway :) so if you have hardware corruption
   problems that don't show up except under heavy load, ext2fs is a good
   filesystem to bring those out :)
   
   And of course, the very reason I posted my original email as part of
   this thread. A person needs to always keep in mind that if they are
   getting ext2fs errors about corruption, this does *NOT* always mean
   the ext2fs is at fault. It means that somewhere along the way, either
   due to code in the ext2fs, or code in the block driver you are using,
   or code in the low level driver you are using, or somewhere between
   the CPU, RAM, cache, bus, controller, drive bus, drive, and magnetic
   media, something is getting corrupted. It is important in these cases
   to try and isolate software faults from hardware faults.
   
   The purpose of the "script" I posted was to give a convenient way of
   trying to narrow down the line between hardware and software. There is
   still software involved with that script, but not as much. You are
   down to just the badblocks program, the various buffer mechanisms, and
   the block driver itself (with its underlying low level driver).
   Generally speaking, the buffer cache is considered to be safe code, so
   you can rule that out. Most of the block drivers are considered to be
   the same, so they can be ruled out. This leaves the underlying low
   level driver and the badblocks program as suspect. The badblocks

 * Message split, to be continued *
--- Gnus v5.4.37/XEmacs 19.15
 * Origin: Linux inside (2:5020/510@fidonet)

_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
 From : Boris Tobotras                      2:5020/510      30 Jun 97  21:06:16 
 Subj : linux-kernel FAQ (2/2)                                                  
________________________________________________________________________________
   arch/i386/boot/compressed/misc.c, same thing. (after make dep clean
   zImage) 
   
   I had this problem. You just need to update loadlin to 1.6a version.
   
   [vps@hydroel]~$ grep loadlin /usr/src/linux/Documentation/Changes
   detection, requiring loadlin users to upgrade to loadlin-1.6a.
   
   [137]<URL:ftp://ftp.suse.com/pub/loadlin/update-1.6a/loadlin.exe.gz>;
   [138]<URL:ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/update-1.6a/l
   oadlin.exe.gz>
   
   Answered by Pawel S. Veselov [139]<URL:mailto:vps@beta.niimm.spb.su>
   
    3.1.5.10. Martian Packets
    
   I am getting the following message in my logs, but only when someone
   is accessing the Linux machine via telnet from another network
   machine. (dev eth0).
   
   Jun 17 06:22:37 newn kernel: martian source 01010101 for 024100c7, dev
   eth0
   Jun 17 06:22:37 newn kernel: ll header: 00 40 05 1d 34 9c 00 a0 24 ac
   18 35 08 00 
   
   Someone on your network believes that he has IP address 1.1.1.1. It is
   unlikely to be correct, is not it? This "someone" has ethernet address
   00:a0:24:ac:18:35.
   
   Answered by A.N.Kuznetsov [140]<URL:kuznet@ms2.inr.ac.ru>
   
3.2. Is there ... ?

  3.2.1 ... an encrypted file system?
  
   "I have recently found a need for an encrypted fs, I have however had
   trouble finding any ones that meet my needs. Is anyone currently
   working on any encrypted file systems, and if not would anyone be
   interested on working on one with me?"
   
   check out cfs (crypted filesystem) which does things nfs-like, and for
   the loop device within linux:
   [141]<URL:ftp://csclub.uwaterloo.ca/pub/linux-stego/index.html>;
   
   Answered by tz@execpc.com
   
  3.2.2 ... a kernel suitable for embedding?
  
   I've got a 68HC360 based device that is being developed and we are
   looking into O/S options. Has anyone done work towards slimming the
   kernel for embedding in small memory footprint devices?
   
   These Web sites are HOT! Er, may be relevant, I mean.
   
     * Memory Savers
       [142]<URL:http://rsphy1.anu.edu.au/~gpg109/mem.html>;
     * ELKS - The Embeddable Linux Kernel subset
       [143]<URL:http://www.linux.org.uk/Linux8086.html>;
     * The Linux/m68k Home Pages
       [144]<URL:http://www.clark.net/pub/lawrencc/linux/>;
       
   Answered by Trevor Johnson [145]<URL:mailto:trevor@jpj.net>
   
  3.2.3 ... a kernel regression test suite?
  
   No, not yet, but people seem to be very interested in that. Anyone who
   starts such a project might have a look at the following resource:
   
   [146]<URL:http://www.itl.nist.gov/div897/ctg>;
   
   Posix conformance test suite, for detecting strange behaviour
   
   Other program suggested for a kernel test suite are stress tools, such
   as lmbench, crashme, bonnie, fork bombs, NFS stress tools and tty
   stress tools. (ttystress might need a null modem adapter)
   
  3.2.4. ... a decent auto mounter?
  
   You can still use amd if you want, but if you want to use autofs, get
   the tools from
   [147]<URL:ftp://ftp.kernel.org/pub/linux/daemons/autofs>;; there is a
   mailing list too that you probably want to subscribe to.
   
   Please note that autofs is currently not very featureful; although we
   do use what there is so far in a production environment here at
   Transmeta.
   
  3.2.5. ... an ACL implementation?
  
   Well, as the "maintainer" of the Linux ACL project, I suppose it's my
   job to announce to everyone that I've hacked (remember that word)
   together a quick design spec. I've also put up a small set of the code
   for everyone to take a look at. Now...as I said, the spec is a real
   hack job (done for a class where paperwork is everything...), and I'd
   appreciate any feedback I can get on it. The code too is a combination
   of Artem Belevich's (the old maintainer) work and my own. I haven't
   had time to really get it all pretty yet, so if anyone wants to
   contribute some effort it would be welcome. All this said...
   
   design spec:
   [148]<URL:http://www.dwc.edu/users/frival/acl/acldesign.html>;
   basic code: [149]<URL:http://www.dwc.edu/users/frival/acl/acl.c>;
   
   I'll be posting a diff to the latest kernel version as soon as I get a
   chance to update my working set (should be around 2.1.94 or so ;-) Any
   feedback/thoughts are more than welcome.
   
    And in a later article:
    
   Well, as I've been promising, I finally got around to setting up a
   list for the ACL project. As far as I know, no one else has already
   set one up. Anyway, the address is, amazingly enough,
   <linux-acl@dwc.edu>. It's a majordomo list, so subscription etc. is
   just like with vger (I hope...).
   
   Announce by Peter Rival [150]<URL:mailto:ops@dwc.edu>
   
  3.2.6. ... a better numbering scheme for SCSI devices?
  
   If we do that, we definitely have to adopt something like the Solaris
   /dev/dsk/c0t0d0s3 scheme. It gets really tiring trying to outguess
   what the kernel is going to name a new disk when it's put online. 
   
   Eric Youngdale wrote a nice utility which does exactly this! Try
   scsidev. I couldn't live without it. Not sure why it never caught on
   with any of the distributions..
   
   Answered by Steven N. Hirsch [151]<URL:mailto:shirsch@ibm.net>
   
   (By the way, Eric Youngdale himself considers scsidev a hack, not as a
   long term solution. On the other hand, scsidev is said to work nicely
   around some current real life problems. -- froh)
   
  3.2.7. ... a lofs?
  
   Now is a very good time to tell me if someone else has already got a
   working lofs :-) 
   
   I wrote one quite some time ago, and finally made patches against
   2.0.30 last week. They're at
   [152]<URL:ftp://dot.superaje.com/pub/linux/lofs-2.0.30.diff>; It's not
   perfect, but it works. (I do have a fancier 2.1.x version, but it'll
   be a while before i get anymore work done on it.)
   
   Answered by Benjamin C R LaHaise
   [153]<URL:mailto:blah@jester.superaje.com>
   
  3.2.8. ... Sys V TLI for Linux?
  
   Go to [154]<URL:ftp://ftp.gcom.com/pub/linux/src/streams-3-31-97>; and
   there you will find LiS-2.0.25.tar.gz -> this is a full implementation
   of STREAMS for Linux, including kernel patches and all... Caldera has
   some documentation in the ftp.caldera.com/pub/stuff/LiS-2.0.24.tar.gz
   file to help you set it up.
   
   Answered by Yoav Cohen-Sivan [155]<URL:mailto:yoavcs@netvision.net.il>
   
  3.2.9. ... a patch that allows for more IP aliases?
  
   What is the limit to the number of IPALIASes?
   
   Arbitrary 256 aliases per device (2.0.30), tuned with internal hash
   table size. Incoming 2.0.31 has dynamic alias limit, allowing better
   hash table sizing, please see
   [156]<URL:ftp://ftp.kernel.org/pub/linux/kernel/davem/>; for
   2.0.31-pre2 patch (I also upgraded
   Documentation/networking/alias.txt).
   
   Answered by Juan Hose Ciarlante
   [157]<URL:mailto:irriga@impsat1.com.ar>
   
3.3. Kernel development

  3.3.1. Tips
  
    3.3.1.1. How to find your way around the kernel
    
   Kernel code includes many include files. Those include files often
   include other include files and so on. If I am looking at a variable
   name in a *.c file which is in another file, how do I easily find it? 
   
   Have a look at the 'etags' or 'ctags' programs. Those programs scan C,
   C++, Assembler, Tex and many other source formats and generate 'tags
   tables' that tell the emacs or vi editors where symbols are defined.
   The programs should be bundled with most Linux distributions.
   
   Also have a look at your nearest sunsite mirror in the /devel/lang/c
   directory, there are a lot of other C cross referencing tools in
   there.
   
  3.3.2. How to get started
  
   Cameron MacKinnon [158]<URL:mailto:mackin@interlog.com> wrote a
   wonderful article on that topic:
   
   "... I'm not a pro, but I generally know what's going on for least
   part of the time. Here's what I did:
   
   I bought books. Here's reviews: LINUX Kernel Internals, Beck et al,
   Addison Wesley, 0-201-87741-4. I read about a third of it. It's dated
   (1.2 kernels) and doesn't have anything about SCSI in it, but it's the
   only Linux kernel book out there. There's a new version out for 2.0
   kernels, but only in the original German. 'The Design and
   Implementation of the 4.4 BSD Operating System', McKusick et al,
   Addison Wesley, 0-201-54979-4. A much more readable book, IMHO. It
   talks about the BSD design in general, why things changed over time,
   why and how specific performance tradeoffs were made, etcetera. Also,
   'The Magic Garden Explained' or something like that, borrowed, pub.
   and ISBN unknown. <See Section 2.1.8 -- froh> This book is a very
   thorough coverage of the design of System 5 Release 4 (SVR4), but not
   as easy to read as the BSD book. Bottom line: Beg, borrow, check out
   or steal one book, any book, on the design of the UNIX operating
   system. Sit in a library or a bookstore reading it, if you haven't got
   the money. You need to understand how schedulers, pagers, swappers,
   top and bottom halves, wait queues, inodes, ttys, the boot process,
   init and some other stuff work. Most of this stuff will be applicable
   to Linux at the concept level, regardless of the book (ignore anything
   on SysV STREAMS). Unless you're extremely gifted, the concepts won't
   reveal themselves to you from kernel source code. LEARN THE CONCEPTS.
   The Linux community is not a good place to do this - this list assumes
   that if you're here, you already know them. If you're one of those
   truly unlucky people with no access to such a book, try to find this
   info on the net. I've never really looked. If all else fails, proceed
   to step two:
   
   I read Michael Johnson's Kernel Hackers' Guide. It wasn't perfect when
   I read it, but that was a while ago. 1) It's probably perfect by now.
   2) It's free. You can get it anywhere, including here:
   [159]<URL:http://www.redhat.com:8080/HyperNews/get/khg.html> It does a
   good job of mapping the concepts you just learned to actual kernel
   function calls and processes in Linux. Also, many kernel functions
   have man pages, though they're horribly out of date.
   
   I subscribed to mailing lists. Initially I was all over: gcc, kernel,
   a few scsi lists, security... Now I've got it down to a core of
   kernel, two SCSI driver lists, DIALD, security and SMP. Don't be
   afraid to subscribe to a lot of lists (read-only!) for a few weeks to
   see what interests you. You can always unsubscribe later. Some people
   prefer reading the lists via news, but I'd recommend mail: You SAVE
   the mail on your hard disk. It becomes your personal reference library
   (N.B. UNIX has some really great text search and processing tools).
   You read all the mail. This gives you a feel for what's being worked
   on and what's not, who knows what they're talking about and who
   doesn't, and what snags are troubling other users. This is important
   so you can ask senior developers PRIVATELY when you have questions
   relating to The Code - unless you genuinely believe that a lot of list
   subscribers also want the answer. Also, some of the news gateways
   appear to be brutally broken, randomly mixing messages from different
   linux lists like a cypherpunk remailer gone mad. I recommend going
   straight to the source: send 'help' to
   mailto:majordomo@vger.rutgers.edu
   
   I quickly got over the idea that I could learn everything about the
   kernel. Last time I looked, it was over 600,000 lines of source. I can
   muck around with SCSI and network device drivers, I understand the mid
   level SCSI code, and I've got a reasonably good handle on the
   scheduler. That leaves high level networking, filesystems, the buffer
   cache and memory management, to name a few, ABOUT WHICH I HAVEN'T A
   CLUE. Pick an area you want to diddle with, and concentrate on that.
   If you don't believe me, grab a dictionary and look up 'hubris'.

 * Message split, to be continued *
--- Gnus v5.4.37/XEmacs 19.15
 * Origin: Linux inside (2:5020/510@fidonet)

_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
 From : Boris Tobotras                      2:5020/510      30 Jun 97  21:06:16 
 Subj : [part 2] linux-kernel FAQ (2/2)                                         
________________________________________________________________________________
 * Continuation 1 of a split message *

   
   I read most (some?) of the important stuff in Documentation/ (you
   should read it all) and then: I dove into the code, wholeheartedly,
   for nights (days?) at a time. Pick drivers. Concentrate on the simple
   ones - you want concepts, not nasty workarounds for buggy hardware.
   Try 'wc *.c|sort' in your favorite directory. Pick ones that look well
   formatted and well commented, and see how they're written and how they
   interact with the higher level stuff. Go into each subdirectory in the
   whole linux/ tree, and learn what lives there. You should be able to
   identify what's what from the stuff you read in those books. Note
   especially mm/ and kernel/, along with their counterparts under arch/.
   Here lie most of the important functions for juggling memory,
   interrupts, processes etcetera. Learn to use grep, find and xargs
   effectively. If you have a strong constitution, look in the scripts/
   directory and the Makefiles everywhere to see how the kernel actually
   gets built. If you're a bit twiddler at heart, look at the low level
   stuff for your favorite architecture under arch/.
   
   If you've still got the lust for knowledge at this point, you will
   probably have found 'that special something' that interests you in the
   kernel. You will know generally how things work from the source, and
   you will know the right people to ask from the source and the mailing
   lists. If you have a question, go ahead and ask it. I've found
   developers to be very helpful when asked questions by someone who's
   obviously studied the sources. Play around. Recompile. Benchmark.
   Test.
   
   One thing that's probably overlooked by a lot of Linux people: BSD,
   'the other free UNIX'. I can't even tell you the difference between
   FreeBSD and NetBSD, but for my purposes, I don't care. They're
   available free on the net or a CD, just like Linux
   [160]<URL:http://ftp.freebsd.org>; and
   [161]<URL:http://www.freebsd.org>;. If you're stumped by something in
   Linux, seeing how BSD does it is often helpful, especially for device
   drivers. Also (ahem) BSD code sometimes seems to be commented and
   formatted somewhat better. I don't run it, I just look at the source.
   
   At this stage your hats will no longer fit, and your dog will have run
   off with your girlfriend. No matter, because you'll be able to ask,
   and sometimes answer, intelligent questions about kernel design, in
   your particular specialty areas. You'll be fixing insidious bugs,
   improving performance, and posting things like 'this patch is from
   memory and untested, but it will solve your problem on 2.1.87: [proper
   patch syntax]'
   
   I'm not at this stage yet, and I've been working at it for a while.
   That's why I usually post answers to questions like 'where do I begin'
   rather than 'why did it hang'. The above is working for me, it might
   work for you. May the Source be With You, Always."
   
                          A. Appendix A - Maintainers
                                       
   This policy and FAQ is currently maintained by Frohwalt Egerer
   [162]<URL:mailto:froh@iconsult.com>. For communication concerning this
   document please use [163]<URL:mailto:kernelfaq@iconsult.com>, that
   mail alias will always point to the current maintainer.
   
   The policy is created from input on the linux kernel mailing list. If
   desired by members of the list a vote will be held to ratify the
   policy.
   
   Thanks to David A Rusling [164]<URL:mailto:rusling@linux.reo.dec.com>
   for providing the foundation to section one. Thanks to Colin Plumb
   [165]<URL:mailto:colin@nyx.net> who refined my proposal for section
   one using his fine taste of language.
   
   Thanks to Cameron MacKinnon [166]<URL:mailto:mackin@interlog.com> for
   his really great article on getting started with kernel development
   which I adopted into this document.
   
   Thanks to Doug Ledford [167]<URL:mailto:dledford@dialnet.net> for his
   excellent description on how to hunt down filesystem corruption
   problems.
   
   Thanks to Eric Hoeltzel [168]<URL:mailto:eric@dogbert.sitewerks.com>
   for the enormous amount of suggestions.
   
   Thanks to Evgeny Rodichev [169]<URL:maito:er@sai.msu.su> for providing
   the ver_linux shell script.
   
   And thanks to W. Reilly Cooley, Kevin Fenzi, Gabriel Paubert, Marc
   Merlin, Tethys, Antoine Reid, Sebastian Benoit, Regis Duchesne,
   Riccardo Facchetti, J. Sean Connel, Seth M. Landsman, Martin Radford,
   James Mastros, Nicholas J. Leon, E.Rodichev, Antoine Reid, Ben
   Clifford, Melissa Johnson, Dave Wreski, Greg Patterson, Keith Rohrer,
   Roch-Alexandre Nomine-Beguin, Raymo, Elliot Lee, Greg Alexander, Billy
   Harvey, Harald Milz, John Carter, Janos Farkas, Tony Gale, Garst R.
   Reese, Peter P. Eiserloh, Axel Boldt, Jakub Jelinek, Duncan Hill, Andi
   Kleen, Steven N. Hirsch, Lars Wirzenius, Donald R. Harter, Tuomas
   Heino, Miguel de Icaza, tc@execpc.com, Trevor Johnson, Peter Eiserloh,
   Torbjorn Lindgren, Mike Wangsmo, Antony Stuckey, Herve Regad-Pellagru,
   David S. Miller, Peter Rival, Steven N. Hirsch, Benjamin C R LaHaise
   and all that I forgot to mention for their input, suggestions and
   articles on the mailing list. This FAQ would not exist without their
   help.
   
   The quote of George B. Shaw in section 1.4 might not be accurate. I
   heard it on German TV, remembered it for a few weeks and translated it
   back to English for this FAQ.
   
           B. Appendix B - Linux Kernel Mailing List Bug Report Form
                                       
   Please use the following form to report bugs to the Linux kernel
   mailing list. Having a standardized bug report form makes it easier
   for you not to overlook things, and easier for the developers to find
   just the little tad of information they're really interested in.
   
   First run the ver_linux script included at the end of this Appendix or
   at [170]<URL:ftp://ftp.sai.msu.su//sai2/ftp/pub/Linux/ver_linux>; It
   checks out the version of some important subsystems.
   
   Use that information to fill in all fields of the bug report form, and
   post it to the mailing list with a subject of "ISSUE: <one line
   summary from [1.]>" for easy identification by the developers
   
    [1.] One line summary of the problem:
    [2.] Full description of the problem/report:
    [3.] Keywords (i.e., modules, networking, kernel):
    [4.] Kernel version (from /proc/version):
    [5.] Output of Oops.. message with symbolic information resolved
           (see Kernel Mailing List FAQ, Section 1.5):
    [6.] A small shell script or example program which triggers the
         problem (if possible)
    [7.] Environment
    [7.1.] Software (add the output of the ver_linux script here)
    [7.2.] Processor information (from /proc/cpuinfo):
    [7.3.] Module information (from /proc/modules):
    [7.4.] SCSI information (from /proc/scsi/scsi):
    [7.5.] Other information that might be relevant to the problem
           (please look in /proc and include all information that you
            think to be relevant):
    [X.] Other notes, patches, fixes, workarounds:

   ver_linux (by Evgeny Rodichev <URL:mailto:er@sai.msu.su>
   
    #!/bin/sh
    # Before running this script please ensure that your PATH is
    # typical as you use for compilation/istallation. I use
    # /bin /sbin /usr/bin /usr/sbin /usr/local/bin, but it may
    # differs on your system.
    #
    echo '-- Versions installed: (if some fields are empty or looks'
    echo '-- unusual then possibly you have very old versions)'
    uname -a
    insmod -V 1>/tmp/ver_linux.tmp 2>>/tmp/ver_linux.tmp
    awk 'NR==1{print "Kernel modules        ",$NF}' /tmp/ver_linux.tmp
    rm -f /tmp/ver_linux.tmp
    echo "Gnu C                 " `gcc --version`
    ld -v 2>&1 | awk -F\) '{print $1}' | awk \
          '/BFD/{print "Binutils              ",$NF}'
    ls -l `ldd /bin/sh | awk '/libc/{print $3}'` | awk -F. \
          '{print "Linux C Library        " $(NF-2)"."$(NF-1)"."$NF}'
    ldd -v | awk '{print "Dynamic Linker (ld.so)", $3}'
    ls -l /usr/lib/libg++.so | awk -F. \
          '{print "Linux C++ Library      " $4"."$5"."$6}'
    ps --version 2>&1 | awk 'NR==1{print "Procps                ", $NF}'
    mount --version | awk -F\- '{print "Mount                 ", $NF}'
    netstat --version | awk \
    'NR==1{if ($5 != "") { n=split($5,buf,"-"); ver=buf[n]; done=1 }}
     NR==2{if (done != 1) ver=$3 }
     END{print "Net-tools             ",ver}'
    loadkeys -h 2>&1 | awk 'NR==1{print "Kbd                   ",$3}'
    expr --v | awk '{print "Sh-utils              ", $NF}'

                       C. Appendix C - Unresolved Issues
                                       
   Mention RFC 1925 section 11 in the policy.
   [171]<URL:http://www.quantum.de/cgi-bin/rfcprint?rfc=1925>;
   
                          D. Appendix D - Change Log
                                       
   $Log: draft,v $
   
   Revision 1.20 1997/06/25 20:06:03 cvs
   
   draft
   
   Revision 1.19 1997/06/25 20:00:14 cvs
   
   Fixed stupid typo.
   
   Revision 1.18 1997/06/25 19:47:17 cvs
   
   Updated the "build" system for the htmlified version of the FAQ
   
   Revision 1.17 1997/06/25 16:28:29 cvs
   
   HTMLified
   
   Revision 1.16 1997/05/02 22:07:04 cvs
   Added a lot of stuff accumulted in my mail box.
   
   Revision 1.15 1997/04/12 22:19:43 cvs
   Minor changes. Removed a resource on request.
   
   Revision 1.14 1997/04/12 16:52:30 cvs
   Added general 'kernel development' subsection, moved the getting
   started below it and added a tips section together with some blurb on
   cross referencing C.
   
   Revision 1.13 1997/04/12 16:15:29 cvs
   Added subsection on kernel nfsd compile problems
   
   Revision 1.12 1997/04/11 14:18:13 cvs
   Added "seasonal problems" sections for "NFS warning" and "Objdump
   problems"
   
   Revision 1.11 1997/04/10 10:24:01 cvs
   Consistent layout (use 2 spaces between sentences)
   Added more information on unsubscribing
   Added examples how to do kernel diffs
   Added SYN Flooding information
   Added P6 Local APIC Information
   Imported ver_linux update by Evgeny Rodichev
   
   Revision 1.10 1997/04/10 07:29:19 cvs
   Contents updated automatically
   
   Revision 1.9 1997/04/07 05:44:23 cvs
   Added a revision header to the top of the draft. Otherwise 1.9 is
   equivalent to 1.8
   
   Revision 1.8 1997/04/07 05:40:09 cvs
   Imported yet another set of suggestions by Eric.
   Imported the ver_linux data collection script of Evgeny Rodichev.
   
   Revision 1.7 1997/04/07 04:32:48 cvs
   FAQ is available on http://kernelfaq.iconsult.com from now on.
   
   Revision 1.6 1997/04/06 22:05:07 cvs
   Imported lots of e-mailed spelling changes for the parts added in 1.5
   Elaborated a bit more on some sections
   First draft of the Bug Report Form
   Included, updated and corrected a number of resources
   Started to use '=' markers so grep will build the table of contents
   for me
   
   Revision 1.5 1997/04/06 02:43:07 cvs
   Fixed typo in Newsgroups: line. Feeling sheepish.
   
   Revision 1.4 1997/04/06 02:41:29 cvs
   Imported spelling and stylistic corrections
   Elaborated on bug reports (section 1.5.)
   Included section 1.6. "Kernel patches"
   Added some new resources to section 2
   Added section 3, and 3.1 (common problems) and move the 'getting
   started' text to 3.2.
   Added a change log (maintained by cvs)
   
   Revision 1.1-1.3 "long ago"
   Early drafts, 1.3 was not released to the public.

References

   1. http://www.iconsult.com/
   2. file://localhost/tmp/FAQ.html#0.
   3. file://localhost/tmp/FAQ.html#1.
   4. file://localhost/tmp/FAQ.html#1.1.
   5. file://localhost/tmp/FAQ.html#1.2.
   6. file://localhost/tmp/FAQ.html#1.3.
   7. file://localhost/tmp/FAQ.html#1.4.
   8. file://localhost/tmp/FAQ.html#1.4.1.
   9. file://localhost/tmp/FAQ.html#1.4.2.
  10. file://localhost/tmp/FAQ.html#1.5.
  11. file://localhost/tmp/FAQ.html#1.6.
  12. file://localhost/tmp/FAQ.html#1.7.
  13. file://localhost/tmp/FAQ.html#2.
  14. file://localhost/tmp/FAQ.html#2.1.
  15. file://localhost/tmp/FAQ.html#2.1.1.
  16. file://localhost/tmp/FAQ.html#2.1.2.
  17. file://localhost/tmp/FAQ.html#2.1.3.

 * Message split, to be continued *
--- Gnus v5.4.37/XEmacs 19.15
 * Origin: Linux inside (2:5020/510@fidonet)

_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
 From : Boris Tobotras                      2:5020/510      30 Jun 97  21:06:16 
 Subj : [part 3] linux-kernel FAQ (2/2)                                         
________________________________________________________________________________
 * Continuation 2 of a split message *

  18. file://localhost/tmp/FAQ.html#2.1.4
  19. file://localhost/tmp/FAQ.html#2.1.5
  20. file://localhost/tmp/FAQ.html#2.1.6.
  21. file://localhost/tmp/FAQ.html#2.1.7.
  22. file://localhost/tmp/FAQ.html#2.1.8.
  23. file://localhost/tmp/FAQ.html#2.1.9.
  24. file://localhost/tmp/FAQ.html#2.1.10.
  25. file://localhost/tmp/FAQ.html#2.2.
  26. file://localhost/tmp/FAQ.html#2.2.1.
  27. file://localhost/tmp/FAQ.html#2.2.2.
  28. file://localhost/tmp/FAQ.html#2.2.3.
  29. file://localhost/tmp/FAQ.html#2.2.4.
  30. file://localhost/tmp/FAQ.html#2.2.5.
  31. file://localhost/tmp/FAQ.html#2.2.6.
  32. file://localhost/tmp/FAQ.html#2.2.7.
  33. file://localhost/tmp/FAQ.html#3.
  34. file://localhost/tmp/FAQ.html#3.1.
  35. file://localhost/tmp/FAQ.html#3.1.1.
  36. file://localhost/tmp/FAQ.html#3.1.2.
  37. file://localhost/tmp/FAQ.html#3.1.3.
  38. file://localhost/tmp/FAQ.html#3.1.4.
  39. file://localhost/tmp/FAQ.html#3.1.5.
  40. file://localhost/tmp/FAQ.html#3.1.5.1.
  41. file://localhost/tmp/FAQ.html#3.1.5.2.
  42. file://localhost/tmp/FAQ.html#3.1.5.3.
  43. file://localhost/tmp/FAQ.html#3.1.5.4.
  44. file://localhost/tmp/FAQ.html#3.1.5.5.
  45. file://localhost/tmp/FAQ.html#3.1.5.6.
  46. file://localhost/tmp/FAQ.html#3.1.5.7.
  47. file://localhost/tmp/FAQ.html#3.1.5.8.
  48. file://localhost/tmp/FAQ.html#3.1.5.9.
  49. file://localhost/tmp/FAQ.html#3.1.5.10.
  50. file://localhost/tmp/FAQ.html#3.2.
  51. file://localhost/tmp/FAQ.html#3.2.1
  52. file://localhost/tmp/FAQ.html#3.2.2
  53. file://localhost/tmp/FAQ.html#3.2.3
  54. file://localhost/tmp/FAQ.html#3.2.4.
  55. file://localhost/tmp/FAQ.html#3.2.5.
  56. file://localhost/tmp/FAQ.html#3.2.6.
  57. file://localhost/tmp/FAQ.html#3.2.7.
  58. file://localhost/tmp/FAQ.html#3.2.8.
  59. file://localhost/tmp/FAQ.html#3.2.9.
  60. file://localhost/tmp/FAQ.html#3.3.
  61. file://localhost/tmp/FAQ.html#3.3.1.
  62. file://localhost/tmp/FAQ.html#3.3.1.1.
  63. file://localhost/tmp/FAQ.html#3.3.2.
  64. file://localhost/tmp/FAQ.html#a.
  65. file://localhost/tmp/FAQ.html#B.
  66. file://localhost/tmp/FAQ.html#C.
  67. file://localhost/tmp/FAQ.html#D.
  68. http://kernelfaq.iconsult.com/
  69. mailto:kernelfaq@iconsult.com
  70. http://www.caldera.com/LDP/Kernel-HOWTO.html
  71. http://sunsite.unc.edu/LDP/Kernel-HOWTO.html
  72. http://www.caldera.com/LDP/
  73. http://sunsite.unc-edu/LDP/
  74. http://www.linuxhq.com/
  75. http://www.ecsnet.com/
  76. http://www.redhat.com:8080/HyperNews/get/khg.html
  77. http://lxr.linux.no/
  78. mailto:majordomo@vger.rutgers.edu
  79. http://www.linuxhq.com/lnxlists
  80. http://www.redhat.com/~johnsonm/devices.html
  81. http://www.cs.uml.edu/~acahalan/linux/wishlist.html
  82. http://www.ssc.com/lj/
  83. http://www.ssc.com/lj/issue23/1219.html
  84. http://www.ssc.com/lj/issue24/kk24.html
  85. http://www.ssc.com/lj/issue25/kk25.html
  86. http://www.ssc.com/lj/issue26/interrupt.html
  87. http://www.caldera.com/LDP/HOWTO/mini/Reading-List
  88. http://sunsite.unc.edu/LDP/HOWTO/mini/Reading-List
  89. http://www.cs.bu.edu/faculty/djy/cs835-fall96.html
  90. mailto:davem@jenolan.rutgers.edu
  91. http://www.linux.org/
  92. http://www.caldera.com/LDP
  93. http://sunsite.unc.edu/LDP
  94. http://www.ssc.com/linux/lsm.html
  95. http://www.ngs.fi/lsm
  96. http://www.boutell.com/lsm
  97. ftp://ftp.execpc.com/pub/lsm/
  98. ftp://cs-pub.bu.edu/pub/irc/clients
  99. news:comp.os.linux.advocacy
 100. news:comp.os.linux.announce
 101. news:comp.os.linux.answers
 102. news:comp.os.linux.development.apps
 103. news:comp.os.linux.development.system
 104. news:comp.os.linux.hardware
 105. news:comp.os.linux.m68k
 106. news:comp.os.linux.misc
 107. news:comp.os.linux.networking
 108. news:comp.os.linux.setup
 109. news:comp.os.linux.x
 110. http://www.ssc.com/lg
 111. ftp://ftp.cs.helsinki.fi/pub/Software/Linux/Kernel/
 112. http://www.ssc.com/linux/web.html
 113. http://sunsite.unc.edu/pub/Linux/
 114. http://sunsite.unc.edu/paulc/incoming.html
 115. http://www.crynwr.com/kchanges/
 116. http://sunsite.unc.edu/linux-source
 117. http://torgo.ml.org/las
 118. http://cesdis1.gsfc.nasa.gov/linux/drivers/
 119. http://www.uk.linux.org/SMP/title.html
 120. http://www.linuxnow.com/
 121. http://www.xnet.com/~blatura/linapps.shtml
 122. http://www.fokus.gmd.de/linux
 123. mailto:dledfor@dialnet.net
 124. ftp://sunsite.unc.edu/pub/Linux/system/misc/memtest86-1.2.tar.gz
 125. http://www.linuxhq.com/patch/20-p0525.html
 126. mailto:kernelfaq@iconsult.com
 127. http://www.bitwizard.nl/sig11
 128. mailto:Eric.Schenk@dna.lth.sh
 129. mailto:lnz@dandelion.com
 130. mailto:jj@sunsite.mff.cuni.cz
 131.
ftp://ftp.mathematik.th-darmstadt.de/pub/linux/okir/linux-nfs-0.4.21.tar.gz
 132. mailto:dhill@sunbeach.net
 133. ftp.mathematik.th-darmstadt.de:/pub/linux/okir/
 134. mailto:okir@monad.swb.de
 135.
file://localhost/../../../mnt/amd/letterman/export/home1/www/content/froh/Eric.S
chenk@dna.lth.se
 136. mailto:hpa@transmeta.com
 137. ftp://ftp.suse.com/pub/loadlin/update-1.6a/loadlin.exe.gz
 138. ftp://elserv.ffm.fgan.de/pub/linux/loadlin-1.6/update-1.6a/loadlin.exe.gz
 139. mailto:vps@beta.niimm.spb.su
 140.
file://localhost/../../../mnt/amd/letterman/export/home1/www/content/froh/kuznet
@ms2.inr.ac.ru
 141. ftp://csclub.uwaterloo.ca/pub/linux-stego/index.html
 142. http://rsphy1.anu.edu.au/~gpg109/mem.html
 143. http://www.linux.org.uk/Linux8086.html
 144. http://www.clark.net/pub/lawrencc/linux/
 145. mailto:trevor@jpj.net
 146. http://www.itl.nist.gov/div897/ctg
 147. ftp://ftp.kernel.org/pub/linux/daemons/autofs
 148. http://www.dwc.edu/users/frival/acl/acldesign.html
 149. http://www.dwc.edu/users/frival/acl/acl.c
 150. mailto:ops@dwc.edu
 151. mailto:shirsch@ibm.net
 152. ftp://dot.superaje.com/pub/linux/lofs-2.0.30.diff
 153. mailto:blah@jester.superaje.com
 154. ftp://ftp.gcom.com/pub/linux/src/streams-3-31-97
 155. mailto:yoavcs@netvision.net.il
 156. ftp://ftp.kernel.org/pub/linux/kernel/davem/
 157. mailto:irriga@impsat1.com.ar
 158. mailto:mackin@interlog.com
 159. http://www.redhat.com:8080/HyperNews/get/khg.html
 160. http://ftp.freebsd.org/
 161. http://www.freebsd.org/
 162. mailto:froh@iconsult.com
 163. mailto:kernelfaq@iconsult.com
 164. mailto:rusling@linux.reo.dec.com
 165. mailto:colin@nyx.net
 166. mailto:mackin@interlog.com
 167. mailto:dledford@dialnet.net
 168. mailto:eric@dogbert.sitewerks.com
 169.
file://localhost/../../../mnt/amd/letterman/export/home1/www/content/froh/maito:
er@sai.msu.su
 170. ftp://ftp.sai.msu.su//sai2/ftp/pub/Linux/ver_linux
 171. http://www.quantum.de/cgi-bin/rfcprint?rfc=1925

-- 
  Best regards, -- Boris.
--- Gnus v5.4.37/XEmacs 19.15
 * Origin: Linux inside (2:5020/510@fidonet)



<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий
Имя:
E-Mail:
Заголовок:
Текст:




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру