ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Lentsov                       2:4615/71.10   15 Nov 2001  17:11:32
 To : All
 Subject : URL: http://www.lwn.net/2001/1115/kernel.php3
 -------------------------------------------------------------------------------- 
 

    [1][LWN Logo] 
    
                                [2]Click Here 
    [LWN.net]
    
    Sections:
     [3]Main page
     [4]Security
     Kernel
     [5]Distributions
     [6]Development
     [7]Commerce
     [8]Linux in the news
     [9]Announcements
     [10]Linux History
     [11]Letters
    [12]All in one big page
    
    See also: [13]last week's Kernel page.
    
 Kernel development
 
    The current kernel release is still 2.4.14. Linus's prepatches are up
    to [14]2.4.15-pre4. For the most part, this prepatch consists of a
    fairly restricted set of patches and updates, along with a fairly
    complete merge from the "ac" kernel series. There were, however, a
    couple of surprises:
      * The ext3 filesystem has been merged; as of 2.4.15, the mainline
        kernel will have two journaling filesystems available. It's marked
        "experimental," of course, but it's a start. As part of the ext3
        merge, the kernel now has a "journal block device" module which is
        intended to provide a generic journaling layer usable by any
        filesystem.
      * The changelog does not mention it, but another goodie that has
        been included is the [15]InterMezzo filesystem. InterMezzo is a
        high-availability, distributed filesystem, with the usual nice
        features (caching, disconnected operation, failover, etc.).
        
    A close reading of the patch turns up a number of User-mode Linux
    configuration options, but UML itself has not yet been merged.
    
    There are no "ac" patches for now; Alan has been working on merging
    his stuff into 2.4.15 instead.
    
    Coding style in the kernel. Code style is one of those issues that
    programmers can argue over indefinitely. So, in a sense, it's
    surprising that the Linux kernel list sees very few discussions on
    this matter. Most of the time, kernel hackers are more concerned about
    the quality of the code, rather than what it looks like.
    
    Thus, a look through the kernel source will turn up a number of
    different ways of formatting code - especially in peripheral pieces
    like drivers. There is an official coding style for the kernel,
    though, as set down (in typical Linus style) in the [16]CodingStyle
    document found in the source tarball. It's introduced in this way:
    
      This is a short document describing the preferred coding style for
      the linux kernel. Coding style is very personal, and I won't
      _force_ my views on anybody, but this is what goes for anything
      that I have to be able to maintain, and I'd prefer it for most
      other things too. Please at least consider the points made here.
      
      First off, I'd suggest printing out a copy of the GNU coding
      standards, and NOT read it. Burn them, it's a great symbolic
      gesture.
      
    If you want to start a debate on a subject, however, all that seems to
    be necessary is to involve perennial target Richard Gooch. A number of
    developers have gone after him for not following the Linus-blessed
    coding style. The argument, essentially, is that, since Richard's code
    is part of the core kernel, it should adhere more closely to the
    coding standards. Numerous other developers need to look at this code,
    they say, and they have a harder time of it as a result of the
    different style.
    
    Richard's [17]response is that it's his code, and, as long as he's
    maintaining it, he should be able to use a style that allows him to
    work efficiently:
    
      And the coding style used elsewhere in the kernel is revolting to
      me. More importantly, it's harder for me to parse than my own
      style. I shouldn't have to constantly stumble over an appalling
      coding style in my own code!
      
    Some kernel hackers could get away with this approach, but Richard is
    running into resistance. One person even [18]submitted a patch
    reformatting one of Richard's subsystems into the standard style.
    Linus didn't accept it - among other things, he doesn't want to be
    doing that sort of tweaking at this particular point in the stable
    kernel series.
    
    If a certain subset of hackers has its way, however, coding standards
    will be more of a concern with future changes to the kernel. Most
    large projects do have such standards, and maybe it's time for the
    kernel to follow suit. It would be a change in the kernel development
    environment, which has always prized the independence of its hackers,
    however.
    
    Are loadable modules free? The question was raised: what sort of speed
    difference is seen when using loadable modules instead of hard-linked
    code? The immediate response from some was "almost nothing," but
    further consideration has shown that not to be true. There are, in
    fact, a number of costs associated with loadable modules.
    
    The biggest, perhaps, relates to how loadable modules are placed in
    kernel memory. The code for a module needs to live in a contiguous
    address space. The kernel sets up that address space with a function
    called vmalloc, which allocates memory with virtual addresses. In
    other words, a loadable module is in an address space that is visible
    to the kernel, but which is separate from where the core kernel code
    goes.
    
    This difference is important. The core kernel address space is a
    direct map of physical memory; it can be handled very efficiently in
    the processor's page table. Indeed, on some processors, a single page
    table entry covers the entire kernel. Space obtained from vmalloc,
    instead, uses one page table entry per memory page. A greater number
    of page table entries means more lookups, and more translation buffer
    misses. One [19]estimate is that the slowdown can be as much as 5%.
    
    Given this problem, why not load modules into the regular kernel
    memory space? Module code requires a contiguous address space. Since
    the standard kernel space is a direct map of physical memory,
    contiguous address spaces must also be contiguous in physical memory.
    Once the system has been running for a while, finding even two
    physically contiguous pages can be a challenge; finding enough to load
    a large module can be almost impossible.
    
    Nonetheless, it turns out that Andrea Arcangeli's kernel patches
    include a feature where the kernel will attempt to find a contiguous
    space for an incoming module. If that attempt fails, the kernel falls
    back to the older vmalloc approach. This change, [20]it is said, makes
    a measurable difference with some benchmarks.
    
    Some architectures (i.e. PowerPC) also have problems going between
    kernel and module code. There can be a substantial amount of setup
    work required every time that transition happens.
    
    Modules also seem to have endemic problems with race conditions - it
    is possible, for example, for the kernel to attempt to access a
    newly-loaded module before it is fully initialized. Modules can also,
    in some situations, be removed while still in use. Such occurrences
    are obviously quite rare, but they can be catastrophic when they
    happen.
    
    The race conditions can be fixed with enough work, but that may
    require changing some fundamental kernel interfaces. In general,
    dealing with loadable modules is not an easy task; as one kernel
    hacker told us in a private message: "Doing live surgery on the kernel
    is never going to be pretty."
    
    Warning about GPLONLY symbols. A little while back, the ability to
    reserve kernel symbols for GPL-licensed modules only was implemented.
    An attempt to load a non-GPL module yields an "unresolved symbols"
    complaint, along with the message: "Note: modules without a GPL
    compatible license cannot use GPLONLY_ symbols." This message has,
    apparently, created a certain amount of user confusion, so the next
    version of modutils will, instead, say something like:
    
      Hint: You are trying to load a module without a GPL compatible
      license and it has unresolved symbols. The module may be trying to
      access GPLONLY symbols but the problem is more likely to be a
      coding or user error. Contact the module supplier for assistance.
      
    This seems like a step in the right direction, but it raises an
    obvious question: why not simply distinguish between the two different
    errors and tell the user exactly what's going on? There is no real
    reason to tell users about GPL-only symbols if the module in question
    is not trying to use any of them.
    
    The [21]answer is that it's just too much trouble, for now. The
    modutils symbol code is getting messy; it will be fixed in 2.5, but,
    for now, the above message is the best that can be done. Besides, says
    modutils maintainer Keith Owens, "Since it only affects BOMs
    [binary-only modules], I don't really care that much about precise
    error messages."
    
    Other patches and updates released this week include:
    
      * Ingo Molnar has posted [22]a scheduler patch which works to keep
        processes running on the same CPU.
      * [23]Release 1.6 of the 2.5 kernel build system is available from
        Keith Owens.
      * Version 1.0.9 of the Journaling Filesystem has been [24]announced
        by Steve Best.
      * [25]Linux-NTFS 1.4.0 has been released by Anton Altaparmakov.
      * Keith Owens has [26]released modutils 2.4.11.
      * Andi Kleen has [27]announced the release of a new snapshot of the
        X86-64 kernel tree.
      * [28]FUSE (Filesystem in USErspace) is a patch, released by Miklos
        Szeredi, that provides an interface for the creation of
        filesystems in user space. It does appear to be an easy interface
        to work with - a [29]Python interface has already been posted.
      * IBM has released [30]version 3.1 of its Dynamic Probes kernel
        debugging facility.
      * Robert Love has released [31]a new preemptible kernel patch; the
        main change this time around is support for the ARM architecture.
      * Richard Gooch has [32]updated his new devfs core implementation.
      * Now that 2.5 appears imminent, Eric Raymond has started putting
        out [33]new releases of the CML2 configuration system.
      * [34]Version 0.51-2.4.14 of the User-mode Linux implementation was
        announced by Jeff Dike.
      * Nick Bellinger has [35]posted an implementation of the Openwall
        SECURE_LINK capability using the security module framework.
      * A new AX.25 release was [36]announced by Jens David, who has also
        announced that he will no longer be maintaining that project.
      * [37]Version 0.7.23 of the access control list implementation for
        Linux was posted by Andreas Gruenbacher.
      * The first public netlink interface for netfilter has been
        [38]announced by J. Schulist.
      * Ben Collins has [39]released version 1.2.4 of SILO, the Sparc boot
        loader.
        
    Section Editor: [40]Jonathan Corbet
    November 15, 2001
    
    For other kernel news, see:
      * [41]Kernel traffic
      * [42]Kernel Newsflash
      * [43]Kernel Trap
    
    Other resources:
      * [44]Kernel Source Reference
      * [45]L-K mailing list FAQ
      * [46]Linux-MM
      * [47]Linux Scalability Effort
      * [48]Kernel Newbies
      * [49]Linux Device Drivers
    
    
    
                                                   [50]Next: Distributions
    
    [51]Eklektix, Inc. Linux powered! Copyright Л 2001 [52]Eklektix, Inc.,
    all rights reserved
    Linux (R) is a registered trademark of Linus Torvalds
 
 References
 
    1. http://lwn.net/
    2. http://ads.tucows.com/click.ng/pageid=001-012-132-000-000-003-000-000-012
    3. http://lwn.net/2001/1115/
    4. http://lwn.net/2001/1115/security.php3
    5. http://lwn.net/2001/1115/dists.php3
    6. http://lwn.net/2001/1115/devel.php3
    7. http://lwn.net/2001/1115/commerce.php3
    8. http://lwn.net/2001/1115/press.php3
    9. http://lwn.net/2001/1115/announce.php3
   10. http://lwn.net/2001/1115/history.php3
   11. http://lwn.net/2001/1115/letters.php3
   12. http://lwn.net/2001/1115/bigpage.php3
   13. http://lwn.net/2001/1108/kernel.php3
   14. http://lwn.net/2001/1115/a/2.4.15-pre4.php3
   15. http://www.inter-mezzo.org/
   16. http://lwn.net/2001/1115/a/CodingStyle.php3
   17. http://lwn.net/2001/1115/a/rg-style.php3
   18. http://lwn.net/2001/1115/a/mtrr.php3
   19. http://lwn.net/2001/1115/a/vmalloc-tlb.php3
   20. http://lwn.net/2001/1115/a/aa-modules.php3
   21. http://lwn.net/2001/1115/a/gplonly.php3
   22. http://lwn.net/2001/1115/a/im-scheduler.php3
   23. http://lwn.net/2001/1115/a/kbuild.php3
   24. http://lwn.net/2001/1115/a/jfs.php3
   25. http://lwn.net/2001/1115/a/ntfs.php3
   26. http://lwn.net/2001/1115/a/modutils.php3
   27. http://lwn.net/2001/1115/a/x86-64.php3
   28. http://lwn.net/2001/1115/a/fuse.php3
   29. http://lwn.net/2001/1115/a/py-fuse.php3
   30. http://lwn.net/2001/1115/a/dp.php3
   31. http://lwn.net/2001/1115/a/preempt.php3
   32. http://lwn.net/2001/1115/a/devfs.php3
   33. http://lwn.net/2001/1115/a/cml.php3
   34. http://lwn.net/2001/1115/a/uml.php3
   35. http://lwn.net/2001/1115/a/securelink.php3
   36. http://lwn.net/2001/1115/a/ax25.php3
   37. http://lwn.net/2001/1115/a/acl.php3
   38. http://lwn.net/2001/1115/a/netlink.php3
   39. http://lwn.net/2001/1115/a/silo.php3
   40. mailto:lwn@lwn.net
   41. http://kt.zork.net/
   42. http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html
   43. http://www.kerneltrap.com/
   44. http://lksr.org/
   45. http://www.tux.org/lkml/
   46. http://www.linux.eu.org/Linux-MM/
   47. http://lse.sourceforge.net/
   48. http://www.kernelnewbies.org/
   49. http://www.xml.com/ldd/chapter/book/index.html
   50. http://lwn.net/2001/1115/dists.php3
   51. http://www.eklektix.com/
   52. http://www.eklektix.com/
 
 --- ifmail v.2.14.os7-aks1
  * Origin: Unknown (2:4615/71.10@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор