ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Lentsov                       2:4615/71.10   22 Nov 2001  17:11:09
 To : All
 Subject : URL: http://www.lwn.net/2001/1122/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 prepatch series is
    up to [14]2.4.15-pre7. Very little beyond basic bugfixes has been
    added to the prepatch in the last week; it appears to be stabilizing.
    The 2.4.15 kernel may have been released by the time you read this.
    
    Where are the "ac" patches? One user asked when Alan Cox would resume
    making patches that tracked the 2.4.15-pre Linus tree. The [15]answer
    would appear to be "not anytime soon." Quoted in full:
    
      Right now I've fed all the stuff I feel makes sense to Linus for
      2.4.15. Once 2.4.15 is out I'll send some more bits to Marcelo, and
      also some bits to Linus that are 2.5 material (eg PnPBIOS). The
      only "-ac" patch as such would be for 32bit quota and other
      oddments so I don't think its worth the effort.
      
    Among such "oddments," of course, is the virtual memory implementation
    that the "ac" series has been using...
    
    How synchronous should Linux be? One day, as Andrew Morton was
    wandering around the filesystem code, he noticed a seeming
    inconsistency. While Linux, like most operating systems that are
    concerned with performance, buffers filesystem writes in the kernels,
    it does provide a couple of ways for the user to request synchronous
    behavior:
      * The "sync" option, used with the mount command, will request
        synchronous writes for every file in the filesystem.
      * The chattr +S command can request synchronous updates for a single
        file or directory.
        
    What Andrew noticed is that, while most operations are indeed
    implemented synchronously, the data actually written to files is not.
    So he posted [16]a patch making writes synchronous as well.
    
    It turns out, though, that there are two types of opinion regarding
    synchronous writes of file data. Linux has never, in the past, had
    that behavior. The claim in the mount man page ("All I/O to the file
    system should be done synchronously.") is simply incorrect. Fully
    synchronous behavior is very expensive, leading to horrible
    performance, and is, according to some, rarely needed. It is better,
    according to this camp, to expect applications to use the fsync()
    system call to explicitly force synchronous behavior when it's needed
    in a specific situation. Rather than implement synchronous file
    writes, these folks (as [17]typified by Stephen Tweedie) propose
    instead to limit implicit synchronous behavior to directories.
    
    On the other side, Jeff Garzik [18]argued that implementing
    synchronous file writes is the correct thing to do. Users sometimes
    need that behavior, and it is impractical to hack up applications and
    scripts to call fsync() explicitly. A separate dirsync mount option
    could provided to request synchronous semantics for directories only.
    
    Amusingly, Andrew [19]appears to have been won over by the first point
    of view, but his patch (implementing the second) found its way into
    2.4.15-pre5. Unless something changes, fully synchronous behavior will
    be the way of things in 2.4.15.
    
    Proposed feature: devlinks. Access to and naming of devices looks like
    it could be one of the truly divisive issues in 2.5 kernel
    development. The current system (static nodes in /dev using device
    numbers) is showing a few signs of strain:
      * The static /dev directly is mismatched with the increasingly
        dynamic nature of hardware. Almost any type of peripheral can come
        and go without notice, but /dev just sits there.
      * As more types of devices are supported by Linux, that static /dev
        directory has to hold more and more entries for hardware that
        might be present on somebody's system. /dev on a modern
        distribution can contain thousands of useless entries.
      * The device number space is running out. Device numbers will be
        expanded in 2.5, but Linus is determined to move away from that
        scheme. For that reason, he is no longer allowing new major
        numbers to be assigned.
        
    One solution to all of these problems, of course, is devfs, which is
    included in the 2.4 kernel. devfs is still not widely used, for a
    number of reasons. Its use requires non-trivial configuration changes,
    and the code contains some race conditions and locking bugs that are
    only now being sorted out. Its use also changes the way policy issues
    (device names and access permissions) are handled. The kernel can not
    remember (or guess) the permissions required for a particular device
    on a given system. This problem is handled with a user-space daemon,
    but not everybody likes that solution.
    
    Neil Brown has come up with [20]an interesting way of dealing with
    some of those issues. His proposal, implementing a feature called
    "devlinks," puts a static administrative layer in front of devfs,
    allowing a system administrator to set up system-specific policy while
    using devfs to get away from device numbers.
    
    A devlink is essentially a new entry point into the devfs filesystem.
    The mechanism is a little clunky at the moment: the administrator
    creates a normal symbolic link, then types a magic mknod command that
    mutates it into a devlink. The devlink then acts as an access point to
    the devfs device. The crucial point, perhaps, is that the devfs
    filesystem itself need not be mounted. If devfs is left unmounted,
    devlinks become the only access path to the device. As such, they can
    be used to set permissions and device naming policy. And, since they
    are stored in a normal filesystem, they are persistent.
    
    The devlink proposal does little for the handling of dynamic devices,
    and a directory full of devlinks could become just as cluttered as the
    current /dev. The proposal seems unlikely to get into the 2.5 kernel
    in its current form. But, as an attempt to work toward a solution to
    the device naming problems facing Linux, it is an interesting
    beginning.
    
    Other patches and updates released this week include:
    
      * [21]Linux-ABI 2.4.14.0 was announced by Christoph Hellwig. This
        patch enables the kernel to support binaries built for a number of
        other operating systems.
      * Richard Gooch has released [22]devfs v197, the first full devfs
        release containing the new, reworked core code.
      * Ben LaHaise has [23]posted a new asynchronous I/O patch.
      * A new multi-queue scheduler patch has been [24]announced by Mike
        Kravetz.
      * A release of the Scalable Test Platform for the 2.4.14 kernel has
        been [25]announced.
      * Andrew Morton has [26]released a new version of his low-latency
        patch for 2.4.15-pre kernels.
      * Jens Axboe has posted [27]version 18 of his patch enabling DMA to
        block devices from high memory. This is the
        "prepare-for-inclusion" version of the patch.
      * Jeff Merkey has [28]announced a new version of the NetWare
        filesystem produced by Timpanogas. There are some [29]doubts out
        there, however, as to just how Novell will react to this release,
        so caution is warranted.
      * [30]mconfig 0.20, a kernel configuration tool, was released by
        Christoph Hellwig.
      * William Irwin has [31]posted a new version of his tree-based boot
        memory allocator.
      * Eric Raymond has released [32]CML2 1.8.7.
      * SGI has [33]announced release 1.0.2 of its XFS filesystem.
      * [34]pcihpview, a graphical tool for working with hotplug PCI
        devices, was released by Greg Kroah-Hartman.
      * [35]Release 1.8 of the new kernel build system is out.
        
    Section Editor: [36]Jonathan Corbet
    November 22, 2001
    
    For other kernel news, see:
      * [37]Kernel traffic
      * [38]Kernel Newsflash
      * [39]Kernel Trap
    
    Other resources:
      * [40]Kernel Source Reference
      * [41]L-K mailing list FAQ
      * [42]Linux-MM
      * [43]Linux Scalability Effort
      * [44]Kernel Newbies
      * [45]Linux Device Drivers
    
    
    
                                                   [46]Next: Distributions
    
    [47]Eklektix, Inc. Linux powered! Copyright Л 2001 [48]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/1122/
    4. http://lwn.net/2001/1122/security.php3
    5. http://lwn.net/2001/1122/dists.php3
    6. http://lwn.net/2001/1122/devel.php3
    7. http://lwn.net/2001/1122/commerce.php3
    8. http://lwn.net/2001/1122/press.php3
    9. http://lwn.net/2001/1122/announce.php3
   10. http://lwn.net/2001/1122/history.php3
   11. http://lwn.net/2001/1122/letters.php3
   12. http://lwn.net/2001/1122/bigpage.php3
   13. http://lwn.net/2001/1115/kernel.php3
   14. http://lwn.net/2001/1122/a/2.4.15-pre7.php3
   15. http://lwn.net/2001/1122/a/ac-patches.php3
   16. http://lwn.net/2001/1122/a/am-sync.php3
   17. http://lwn.net/2001/1122/a/sct-sync.php3
   18. http://lwn.net/2001/1122/a/jg-sync.php3
   19. http://lwn.net/2001/1122/a/am-semantics.php3
   20. http://lwn.net/2001/1122/a/devlinks.php3
   21. http://lwn.net/2001/1122/a/linux-abi.php3
   22. http://lwn.net/2001/1122/a/devfs.php3
   23. http://lwn.net/2001/1122/a/aio.php3
   24. http://lwn.net/2001/1122/a/mqs.php3
   25. http://lwn.net/2001/1122/a/stp.php3
   26. http://lwn.net/2001/1122/a/low-latency.php3
   27. http://lwn.net/2001/1122/a/block-highmem.php3
   28. http://lwn.net/2001/1122/a/ntfs.php3
   29. http://lwn.net/2001/1122/a/ntfs-doubts.php3
   30. http://lwn.net/2001/1122/a/mconfig.php3
   31. http://lwn.net/2001/1122/a/bootmem.php3
   32. http://lwn.net/2001/1122/a/cml.php3
   33. http://lwn.net/2001/1122/a/xfs.php3
   34. http://lwn.net/2001/1122/a/pcihpview.php3
   35. http://lwn.net/2001/1122/a/kbuild.php3
   36. mailto:lwn@lwn.net
   37. http://kt.zork.net/
   38. http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html
   39. http://www.kerneltrap.com/
   40. http://lksr.org/
   41. http://www.tux.org/lkml/
   42. http://www.linux.eu.org/Linux-MM/
   43. http://lse.sourceforge.net/
   44. http://www.kernelnewbies.org/
   45. http://www.xml.com/ldd/chapter/book/index.html
   46. http://lwn.net/2001/1122/dists.php3
   47. http://www.eklektix.com/
   48. http://www.eklektix.com/
 
 --- ifmail v.2.14.os7-aks1
  * Origin: Unknown (2:4615/71.10@fidonet)
 
 

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