1. 26 Jan, 2013 10 commits
  2. 23 Jan, 2013 23 commits
  3. 22 Jan, 2013 7 commits
    • David S. Miller's avatar
      Merge branch 'legacy-isa-delete' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux · 930d52c0
      David S. Miller authored
      Paul Gortmaker says:
      
      ====================
      The Ethernet-HowTo was maintained for roughly 10 years, from 1993 to 2003.
      Fortunately sane hardware probing and auto detection (via PCI and ISA/PnP)
      largely made the document a relic of the past, hence it being abandoned
      a decade ago.
      
      However, there is one last useful thing that we can extract from the
      effort made in maintaining that document.  We can use it to guide us
      with respect to what rare, experimental and/or super ancient 10Mbit
      ISA drivers don't make sense to maintain in-tree anymore.
      
      Nobody will argue that ISA is obsolete.  Availability went away at about
      the time Pentium3 motherboards moved from 500MHz Slot1/SECC processors
      to the green 500MHz Socket 370 Pentium3 chips, at the turn of the century.
      
      In theory, it is possible that someone could still be running one of these
      12+ year old P3 machines and want 3.9+ bleeding edge kernels (but unlikely).
      In light of the above (remote) possibility, we can defer the removal of some
      ISA network drivers that were highly popular and well tested.  Typically
      that means the stuff more from the mid to late '90s, some with ISA PnP
      support, like the 3c509, the wd/SMC 8390 based stuff, PCnet/lance etc.
      
      But a lot of other drivers, typically from the early 1990s were for rare
      hardware, and experimental (to the point of requiring a cron job that would
      do a test ping, and then ifconfig down/up and/or a rmmod/insmod!).  And
      some of these drivers (znet, and lp486e to name two) are physically tied
      to platforms with on motherboard ethernet -- of 486 machines that date
      from the early 1990s and can only have single digit amounts of memory.
      
      What I'd like to achieve here with this series, is to get rid of those old
      drivers that are no longer being used.  In an earlier discussion where
      I'd proposed deleting a single driver, Alan suggested we instead dump
      all the historical stuff in one go, to make it "...immediately obvious
      where the break point is..."[1] and that it was "perfectly reasonable it
      (and a pile of other ISA cards) ought to be shown the door"[2].  So that
      is the goal here - make a clear line in the sand where the really ancient
      stuff finally gets kicked to the curb.
      
      Two old parallel port drivers are considered for removal here as well,
      since in early 386/486 ISA machines, the parallel port was typically found
      with the UARTS on the multi-I/O ISA controller card.  These drivers also date
      from the early 1990's; parallel ports are no longer found on modern boards,
      and their performance was not even capable of 10% of 10Mbit bandwidth.
      
      Allow me a preemptive justification against the inevitable comments from
      well meaning bystanders who suggest "why not just leave all this alone?".
      Dead drivers cost us all if they are left in tree.  If you think that
      is false, then please first consider:
      
      -every time you type "git status", you are checking to see if modifications
       have been made by you to all that dead code.
      
      -every time you type "git grep <regex>" you are searching through files
       which contain that dead code that simply does not interest you.
      
      -every time you build a "allyesconfig" and an "allmodconfig" (don't tell
       me you skip this step before submitting your changes to a maintainer),
       you waste CPU cycles building this dead code.
      
      -every time there is a tree wide API change, or cleanup, or file relocation,
       we pay the cost of updating dead code, or moving dead code.
      
      -daily regression tests (take linux-next as the most transparent
       example) spend time building (and possibly running) this dead code.
      
      -hard working people who regularly run auditing tools looking for lurking
       bugs (sparse/coverity/smatch/coccinelle) are wasting time checking for,
       and fixing bugs in this dead code.
      
      This last one is key.  Please take a look at the git history for the
      files that are proposed for removal here.  Look at the git history for
      any one of them ("git whatchanged --follow drivers/net/.../driver.c")
      Mentally sort the changes into two bins -- (1) the robotic tree-wide
      changes, and (2) the "look I found a real run-time bug while using this"
      category.  You will see that category #2 is essentially empty.
      
      Further to that, realize that drivers don't simply disappear.  We are
      not operating in the binary-only distribution space like other OS.  All
      these drivers remain in the git history forever.  If a person is an
      enthusiast for extreme legacy hardware, they are probably already
      customizing their kernel source and building it themselves to support
      such systems.  Also keep in mind that they could still build the 3.8
      kernel exactly as-is, and run it (or a 3.8.x stable variant of it) for
      several more years if they were really determined to cling to these old
      experimental ISA drivers for some reason.
      
      In summary, I hope that folks can be pragmatic about this, and not
      get swept up in nostalgia.  Ask yourself whether it is realistic to
      expect a person would have a genuine use case where they would
      need to build a 3.9+ modern kernel and install it on some legacy hardware
      that has no option but to absolutely _require_ one of the drivers
      that are deleted here.
      
      The following series was created with --irreversible-delete for
      ease of review (it skips showing the content of files that are
      deleted); however the complete patches can be pulled as per below.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      930d52c0
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
    • YOSHIFUJI Hideaki / 吉藤英明's avatar
      neigh: Keep neighbour cache entries if number of them is small enough. · 2724680b
      YOSHIFUJI Hideaki / 吉藤英明 authored
      Since we have removed NCE (Neighbour Cache Entry) reference from
      routing entries, the only refcnt holders of an NCE are its timer
      (if running) and its owner table, in usual cases.  As a result,
      neigh_periodic_work() purges NCEs over and over again even for
      gateways.
      
      It does not make sense to purge entries, if number of them is
      very small, so keep them.  The minimum number of entries to keep
      is specified by gc_thresh1.
      Signed-off-by: default avatarYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2724680b
    • Nicolas Dichtel's avatar
      ipmr: fix sparse warning when testing origin or group · 360eb5da
      Nicolas Dichtel authored
      mfc_mcastgrp and mfc_origin are __be32, thus we need to convert INADDR_ANY.
      Because INADDR_ANY is 0, this patch just fix sparse warnings.
      Reported-by: default avatarFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      360eb5da