ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Sergey Lentsov                       2:4615/71.10   14 Jun 2001  17:11:11
 To : All
 Subject : URL: http://lwn.net/2001/0614/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.5. Linus released
    [15]2.4.6pre3 on June 13. It includes a relatively large set of fixes
    and updates, including the long-awaited fix that allows ReiserFS
    filesystems to be exported by NFS; a number of virtual memory updates;
    a bunch of virtual filesystem cleanups by Alexander Viro; and many
    other fixes. Linus didn't see fit to mention it, but, as of pre2, the
    kernel also contains a Bluetooth protocol implementation.
    
    The VM changes include work from a number of developers. After some
    rigorous testing here at LWN Labs (i.e. "run it on your desktop and
    see what happens"), we conclude that a number of the VM issues have,
    in fact, been addressed. It is not perfect, yet, but progress is being
    made. It's nice to have a system that doesn't seem to be running out
    of swap all the time.
    
    On the other hand, there have been reports of compile-time warnings
    due, as it turns out, to [16]a change in the PCI bus API. One might
    object that this is supposed to be a stable kernel series; evidently
    the kernel developers concluded that there were few users of this
    particular interface and a change would not cause problems. Some
    people [17]disagree, however.
    
    The 32-bit DMA zone patch, covered [18]last week, is still not present
    in the 2.4.6 prepatch. Linus likes the idea, but [19]wants some
    changes which create a new interface for setting up memory zones in a
    more flexible manner.
    
    Alan Cox's latest is [20]2.4.5ac13. Alan is evidently doing jury duty,
    and has thus been relatively quiet.
    
    A new networking patch pushes the limits of what modules can do. La
    Monte Yarroll is working on the [21]Linux Kernel SCTP project, which
    is producing a Stream Control Transmission Protocol implementation for
    Linux. The SCTP folks have found that it is hard to just plug a new
    networking protocol into the kernel - the interfaces are just not set
    up for that.
    
    So Mr. Yarroll has posted [22]a patch which creates a new registration
    interface. The current static tables are replaced with a dynamic
    structure, and a set of functions has been provided which allows a
    module to add its new protocol to the system. It seems like a useful
    patch, which should not be overly controversial.
    
    Until, that is, somebody asked if this interface could be used to
    replace the TCP implementation in the kernel. The answer was "yes,"
    though any hopes of having the new implementation pick up existing
    connections should be forgotten.
    
    Here's [23]David Miller's take on the idea of plugging in new TCP
    implementations:
    
      I will never in my lifetime allow such a facility to be added to
      the Linux kernel.
      
    One might safely conclude that he does not like the idea.
    
    The problem is that David does not want to open the door for people to
    plug proprietary TCP implementations into the kernel. Linus has, of
    course, said that non-free kernel modules are OK, as long as they
    stick to the published module interface. That interface currently does
    not allow the replacement of network protocol stacks, so the only way
    to do so would be to link the new implementation directly. Doing so
    with a proprietary implementation would clearly violate the GPL. Mr.
    Miller (and many others) are happy with that state of affairs.
    
    This approach is not particularly new or surprising - Linus does not
    allow modules to add new system calls for the same reason. Binary-only
    kernel modules are tolerated, grudgingly, but only for certain tasks,
    such as driving devices. "Embracing and extending" the kernel by
    replacing whole subsystems goes a little too far. Of course, as was
    covered [24]on the LWN front page two weeks ago, some people [25]think
    that even Linus's interpretation is too liberal.
    
    So the registration patch will probably see some minor reworking so
    that it does not allow the replacement of existing network protocols.
    But the issue of binary modules is likely to return, soon. There may
    yet come a point where they are no longer allowed.
    
    The kernel and data formats. Another area of ongoing discussion has to
    do with how the kernel returns data to user space. [26]Last week's
    Kernel Page mentioned the discussion of temperature formats; this
    discussion is worth revisiting (along with one other) because they
    illustrate how some kernel interface decisions are made.
    
    Last week we reported that kelvins were the likely choice of units for
    temperatures reported by CPU monitors and such. In fact, a number of
    people have been advocating for temperatures to be reported in tenths
    of kelvins, or even hundredths. The stated advantages of this format
    are that the numbers will always be non-negative, and that a very wide
    range of temperatures can be represented with 16 bits - a wider range,
    certainly, than most computers will endure and be expected to still
    function. Or so it seems.
    
    The assertion that kelvins can not be negative was quickly refuted,
    but [27]the argument is mostly of interest to pedantic quantum physics
    enthusiasts. Once again, this is not within the normal operating
    specifications of current commodity hardware.
    
    Using anything other than straight kelvins has also been
    controversial. The point being made is that returning a value in
    hundredths of kelvins might fool people into believing that the
    temperature measurements are actually that accurate. One degree of
    precision is more than adequate for modern CPU temperature sensors,
    and a more precise measurement would be useless even if it were
    accurate.
    
    Nonetheless, there are people who would like the more precise format,
    for the simple reason that it may be needed in the future, and these
    interfaces are hard to change once they are in use. A final resolution
    has not happened, but a likely format will be tenths of kelvins, since
    ACPI already uses the format.
    
    Some people have argued for a system configuration option which would
    allow selection of whatever temperature unit pleases the user best.
    That didn't get very far, though. There is a near consensus that the
    kernel should export a single, well-defined format, and leave
    conversions to user space.
    
    The same idea, however, created a bit more fuss at the end of May,
    when a new version of the Phillips web camera driver was merged with
    its color conversion routines stripped out. As a result, applications
    using that camera see only one format, and many of them apparently do
    not understand it. The pwc driver author has [28]summarized his
    position, along with much of the discussion, on his web page.
    
    The argument here is the same: the kernel should export a single data
    format, and leave conversions to user space. In the case of web
    cameras, the kernel hackers would much rather see a single, user-space
    conversion library, rather than a whole set of duplicated conversion
    routines in each driver. Driver writers, who want to make their
    devices easily usable, may disagree, however. The kernel hackers say
    what goes in, though, so this policy is likely to remain.
    
    Other patches and updates released this week include:
    
      * Pavel Roskin has [29]posted a patch which provides devfs support
        for USB scanners.
      * IBM [30]released version 0.3.4 of its journaling filesystem.
      * For those who would like to try out the ext3 filesystem, but who
        aren't up to applying the patches, Peter Braam has [31]released a
        set of RPMs containing an ext3-enabled kernel.
      * The latest reports from the Stanford checker include [32]15
        security holes (some of which were [33]acknowledged to be nasty),
        and [34]a couple of potential deadlocks.
      * There is [35]a new man pages release from Andries Brouwer; it
        exceeds 1000 pages for the first time, and adds pages for a number
        of previously undocumented system calls.
      * Tom Gall at IBM has [36]announced a port to 64-bit PowerPC
        processors. As an example of the scale of machines that are to be
        built with this processor, consider [37]this other note from Tom
        wondering how he can deal with the current limit of 256 PCI buses.
      * Work continues on the security module patch. Here is [38]a version
        of the patch posted by Stephen Smalley with a number of new
        features. Greg Kroah-Hartman responded with [39]a patch of his own
        that takes a slightly different approach.
        
    Section Editor: [40]Jonathan Corbet
    June 14, 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 Project
      * [48]Kernel Newbies
    
    
    
                                                   [49]Next: Distributions
    
    [50]Eklektix, Inc. Linux powered! Copyright Л 2001 [51]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/0614/
    4. http://lwn.net/2001/0614/security.php3
    5. http://lwn.net/2001/0614/dists.php3
    6. http://lwn.net/2001/0614/desktop.php3
    7. http://lwn.net/2001/0614/devel.php3
    8. http://lwn.net/2001/0614/commerce.php3
    9. http://lwn.net/2001/0614/press.php3
   10. http://lwn.net/2001/0614/announce.php3
   11. http://lwn.net/2001/0614/history.php3
   12. http://lwn.net/2001/0614/letters.php3
   13. http://lwn.net/2001/0614/bigpage.php3
   14. http://lwn.net/2001/0607/kernel.php3
   15. http://lwn.net/2001/0614/a/2.4.6pre3.php3
   16. http://lwn.net/2001/0614/a/pci-changes.php3
   17. http://lwn.net/2001/0614/a/pci-gripe.php3
   18. http://lwn.net/2001/0607/kernel.php3
   19. http://lwn.net/2001/0614/a/lt-zones.php3
   20. http://lwn.net/2001/0614/a/2.4.5ac13.php3
   21. http://www.sourceforge.net/projects/lksctp
   22. http://lwn.net/2001/0614/a/sockreg.php3
   23. http://lwn.net/2001/0614/a/absolutely-not.php3
   24. http://lwn.net/2001/0531/
   25. http://lwn.net/2001/0614/a/ac-modules.php3
   26. http://lwn.net/2001/0607/kernel.php3
   27. http://lwn.net/2001/0614/a/negative-kelvins.php3
   28. http://www.smcc.demon.nl/webcam/driver-reject.html
   29. http://lwn.net/2001/0614/a/usb-scanner-devfs.php3
   30. http://lwn.net/2001/0614/a/jfs.php3
   31. http://lwn.net/2001/0614/a/ext3-rpms.php3
   32. http://lwn.net/2001/0614/a/sc-security.php3
   33. http://lwn.net/2001/0614/a/ac-sc-security.php3
   34. http://lwn.net/2001/0614/a/sc-deadlocks.php3
   35. http://lwn.net/2001/0614/a/man-pages.php3
   36. http://lwn.net/2001/0614/a/linuxppc64.php3
   37. http://lwn.net/2001/0614/a/pci-bus-limit.php3
   38. http://lwn.net/2001/0614/a/sm1.php3
   39. http://lwn.net/2001/0614/a/sm2.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://www.citi.umich.edu/projects/linux-scalability/
   48. http://www.kernelnewbies.org/
   49. http://lwn.net/2001/0614/dists.php3
   50. http://www.eklektix.com/
   51. http://www.eklektix.com/
 
 --- ifmail v.2.14.os7-aks1
  * Origin: Unknown (2:4615/71.10@fidonet)
 
 

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