ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Lentsov                       2:4615/71.10   12 Jul 2001  16:16:03
 To : All
 Subject : URL: http://www.lwn.net/2001/0712/kernel.php3
 -------------------------------------------------------------------------------- 
 

    [1][LWN Logo] 
    
                                [2]Click Here 
    [LWN.net]
    
    Sections:
     [3]Main page
     [4]Security
     Kernel
     [5]Distributions
     [6]On the Desktop
     [7]Development
     [8]Commerce
     [9]Linux in the news
     [10]Announcements
     [11]Linux History
     [12]Letters
    [13]All in one big page
    
    See also: [14]last week's Kernel page.
    
 Kernel development
 
    The current kernel release is still 2.4.6. The latest 2.4.7 prepatch
    from Linus is [15]2.4.7pre6, which contains another set of fixes and
    updates.
    
    Alan Cox's [16]2.4.6ac2 was released on July 7; it contains, as usual,
    a rather longer list of fixes. Andrea Arcangeli also has a prepatch
    ([17]2.4.7pre5aa1) out with a set of fixes, mostly to the core kernel
    code.
    
    On the 2.2 front, the current prepatch is [18]2.2.20pre7, released on
    July 4.
    
    Building the initial root filesystem into the kernel image. One
    often-heard theme in the ACPI discussion (covered [19]last week) was
    that it would be nice to move much of the ACPI setup into user space.
    That way, perhaps, it would not be necessary to bloat the kernel
    memory footprint with a few hundred kilobytes of ACPI code. But, with
    current kernels, doing boot-time stuff in user space involves using
    the "initrd" (initial RAMdisk) functionality, which not everybody
    likes. Even Linus dislikes it.
    
    But there are advantages to having an initial root filesystem handy;
    it's the clunkiness of the initrd interface that people object to. So,
    Linus [20]has another idea: why not just append a root filesystem, in
    tar format, to the kernel executable image? That way, it can be set up
    in an entirely automatic way, and everything the kernel needs will be
    right at hand. Linus likes this idea enough that he would likely
    [21]make it a mandatory part of the boot process.
    
    Once you have the initial root as part of the kernel image, you can
    move a lot of stuff over. For example, the whole process of finding
    the real, permanent root, and finding and running the init process
    could live there. That would remove a bunch of code from the kernel
    itself, and make it far easier to customize for specific situations.
    It would no longer be necessary to have a DHCP implementation in the
    kernel for diskless systems. And one could even [22]put the kernel
    configuration file there, satisfying a perennial request.
    
    Given that, with a proper implementation, most users would not even
    have to know that this "piggyback" filesystem is present, its
    implementation in the 2.5 series seems likely.
    
    How to do 64-bit PCI DMA? In past weeks we have looked at efforts to
    make it possible to perform DMA I/O operations from anywhere in the
    first 4GB of memory on the system. That would be a significant
    improvement over the current situation, but it still leaves out an
    important case. Large server systems, anymore, can contain well over
    4GB of memory, and there do exist PCI cards which can perform DMA with
    64-bit physical addresses. For such systems, wouldn't it be nice to
    take advantage of the 64-bit mode and eliminate the hassles of memory
    zones and bounce buffers entirely?
    
    The folks working on the IA-64 port decided this would be a good idea.
    Accordingly, they turned dma_addr_t (an internal "cookie" type used by
    the DMA support routines) into a 64-bit quantity, and changed the
    semantics of pci_set_dma_mask() to allow drivers to specify that their
    hardware can do 64-bit DMA. This interface works for the immediate
    needs the IA-64 porters had, but David Miller, who "owns" the PCI DMA
    interface, has made it clear that he opposes moving it to the other
    architectures. Instead, he wants to see a more comprehensive 64-bit
    DMA interface designed and implemented in the 2.5 development series.
    (Those interested in the current interface, incidentally, can see the
    excellent [23]DMA-mapping.txt file found in the kernel source
    documentation directory).
    
    Some people are unhappy with that position; after all, anything
    deferred to 2.5 might not see a stable release for another two years.
    But David's objections make some sense, and they give an interesting
    view into the issues you have to take into account when designing this
    sort of interface. The discussion may look like a complaint session,
    but it is really the initial design work for a high-performance DMA
    interface.
    
    Some of the issues with the simple extension used by IA-64 are:
      * There is little desire to expand dma_addr_t to 64 bits when the
        vast majority of its users will never perform 64-bit DMA. An extra
        32 bits of temporary space may seem small compared to the cost of
        performing an I/O operation, but every bit counts. So a more
        likely solution is a new type (dma64_addr_t, perhaps) and a
        separate interface to go with it.
      * On some systems and peripherals, 64-bit DMA is significantly
        slower than the standard, single-cycle 32-bit version. On such
        systems, 32-bit DMA may be preferable even if it involves things
        like bounce buffers in the CPU.
      * Reasonable hardware (quite a bit of hardware isn't) includes an
        I/O memory management unit (IOMMU) which provides a type of
        virtual memory for peripherals. The IOMMU can cause all operations
        to occur within the 32-bit range. It also has the nice feature of
        making scattered pages look physically contiguous. On such
        systems, you normally do not want to bother with 64-bit
        operations...
      * ...except in cases where you will be performing very large
        transfers. In the worst case, huge operations can take up most or
        all of the IOMMU mapping registers, choking I/O in the rest of the
        system. Devices with this sort of I/O pattern are better off using
        64-bit I/O even if it is slower. A 64-bit DMA interface must allow
        a driver to make this sort of decision.
      * The IA-64 scheme will not work well on 32-bit systems (which can
        still have 64-bit physical addresses) because it relies on the
        existence of kernel virtual addresses for the DMA buffers. 32-bit
        systems with large amounts of memory do not have kernel-space
        mappings for much of that memory. A truly portable interface must
        use struct page pointers rather than virtual addresses.
        
    Chances are good that some sort of 64-bit DMA API which addresses the
    above issues will find its way into 2.5. Thereafter, it may even be
    backported to 2.4, at which point it will be widely available.
    
    Other patches and updates released this week include:
    
      * Marcelo Tosatti has [24]a patch which provides improved virtual
        memory statistics from the kernel.
      * Eric Raymond has posted a [25]State of CML2 message on where the
        new configuration system is. ("The dungeon walls in CML2 adventure
        now occasionally feature entertaining grafitti. Spot all the
        in-jokes and collect a valuable no-prize.")
      * Alexander Viro is [26]looking for testers for his patch to the
        Minix filesystem that moves directories into the page cache.
      * Andrew Morton has [27]a new ext3 patch for 2.4 kernels. This patch
        is not just a port, though; he has included a number of fixes and
        has also reworked things to minimize the number of changes
        required to the core kernel.
      * Davide Libenzi has posted [28]a new /dev/poll implementation
        which, he claims, provides the most efficient notification
        interface for busy network servers.
      * The latest [29]security module patch was posted on July 6.
      * Harald Welte will be [30]giving presentations on netfilter at
        several upcoming Linux events.
      * Greg Kroah-Hartman has posted [31]an updated Compaq/Intel PCI
        hotplug driver.
      * [32]devfs v182 was released by Richard Gooch.
        
    Section Editor: [33]Jonathan Corbet
    July 12, 2001
    
    For other kernel news, see:
      * [34]Kernel traffic
      * [35]Kernel Newsflash
      * [36]Kernel Trap
    
    Other resources:
      * [37]Kernel Source Reference
      * [38]L-K mailing list FAQ
      * [39]Linux-MM
      * [40]Linux Scalability Project
      * [41]Kernel Newbies
    
    
    
                                                   [42]Next: Distributions
    
    [43]Eklektix, Inc. Linux powered! Copyright Л 2001 [44]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/0712/
    4. http://lwn.net/2001/0712/security.php3
    5. http://lwn.net/2001/0712/dists.php3
    6. http://lwn.net/2001/0712/desktop.php3
    7. http://lwn.net/2001/0712/devel.php3
    8. http://lwn.net/2001/0712/commerce.php3
    9. http://lwn.net/2001/0712/press.php3
   10. http://lwn.net/2001/0712/announce.php3
   11. http://lwn.net/2001/0712/history.php3
   12. http://lwn.net/2001/0712/letters.php3
   13. http://lwn.net/2001/0712/bigpage.php3
   14. http://lwn.net/2001/0704/kernel.php3
   15. http://lwn.net/2001/0712/a/2.4.7pre6.php3
   16. http://lwn.net/2001/0712/a/2.4.6-ac2.php3
   17. http://lwn.net/2001/0712/a/2.4.7pre5aa1.php3
   18. http://lwn.net/2001/0712/a/2.2.20pre7.php3
   19. http://lwn.net/2001/0704/kernel.php3
   20. http://lwn.net/2001/0712/a/lt-bzimage-tarball.php3
   21. http://lwn.net/2001/0712/a/lt-always.php3
   22. http://lwn.net/2001/0712/a/ac-config.php3
   23. http://lwn.net/2001/0712/a/dma-interface.php3
   24. http://lwn.net/2001/0712/a/vm-stats.php3
   25. http://lwn.net/2001/0712/a/state-of-cml.php3
   26. http://lwn.net/2001/0712/a/minix.php3
   27. http://lwn.net/2001/0712/a/ext3-2.4.php3
   28. http://lwn.net/2001/0712/a/devpoll.php3
   29. http://lwn.net/2001/0712/a/lsm.php3
   30. http://lwn.net/2001/0712/a/netfilter-talks.php3
   31. http://lwn.net/2001/0712/a/pci-hotplug.php3
   32. http://lwn.net/2001/0712/a/devfs.php3
   33. mailto:lwn@lwn.net
   34. http://kt.zork.net/
   35. http://www.atnf.csiro.au/~rgooch/linux/docs/kernel-newsflash.html
   36. http://www.kerneltrap.com/
   37. http://lksr.org/
   38. http://www.tux.org/lkml/
   39. http://www.linux.eu.org/Linux-MM/
   40. http://www.citi.umich.edu/projects/linux-scalability/
   41. http://www.kernelnewbies.org/
   42. http://lwn.net/2001/0712/dists.php3
   43. http://www.eklektix.com/
   44. http://www.eklektix.com/
 
 --- ifmail v.2.14.os7-aks1
  * Origin: Unknown (2:4615/71.10@fidonet)
 
 

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