1. 15 Apr, 2012 1 commit
  2. 28 Nov, 2010 1 commit
  3. 17 May, 2010 3 commits
  4. 07 Apr, 2010 1 commit
  5. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  6. 29 Nov, 2009 1 commit
  7. 16 Jun, 2009 1 commit
  8. 08 Feb, 2007 2 commits
  9. 03 Jan, 2007 1 commit
  10. 22 Mar, 2006 1 commit
    • Shaun Pereira's avatar
      [X25]: allow ITU-T DTE facilities for x25 · a64b7b93
      Shaun Pereira authored
      Allows use of the optional user facility to insert ITU-T
      (http://www.itu.int/ITU-T/) specified DTE facilities in call set-up x25
      packets.  This feature is optional; no facilities will be added if the ioctl
      is not used, and call setup packet remains the same as before.
      
      If the ioctls provided by the patch are used, then a facility marker will be
      added to the x25 packet header so that the called dte address extension
      facility can be differentiated from other types of facilities (as described in
      the ITU-T X.25 recommendation) that are also allowed in the x25 packet header.
      
      Facility markers are made up of two octets, and may be present in the x25
      packet headers of call-request, incoming call, call accepted, clear request,
      and clear indication packets.  The first of the two octets represents the
      facility code field and is set to zero by this patch.  The second octet of the
      marker represents the facility parameter field and is set to 0x0F because the
      marker will be inserted before ITU-T type DTE facilities.
      
      Since according to ITU-T X.25 Recommendation X.25(10/96)- 7.1 "All networks
      will support the facility markers with a facility parameter field set to all
      ones or to 00001111", therefore this patch should work with all x.25 networks.
      
      While there are many ITU-T DTE facilities, this patch implements only the
      called and calling address extension, with placeholders in the
      x25_dte_facilities structure for the rest of the facilities.
      
      Testing:
      
      This patch was tested using a cisco xot router connected on its serial ports
      to an X.25 network, and on its lan ports to a host running an xotd daemon.
      
      It is also possible to test this patch using an xotd daemon and an x25tap
      patch, where the xotd daemons work back-to-back without actually using an x.25
      network.  See www.fyonne.net for details on how to do this.
      Signed-off-by: default avatarShaun Pereira <spereira@tusc.com.au>
      Acked-by: default avatarAndrew Hendry <ahendry@tusc.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a64b7b93
  11. 29 Aug, 2005 1 commit
    • David S. Miller's avatar
      [NET]: Kill skb->real_dev · f2ccd8fa
      David S. Miller authored
      Bonding just wants the device before the skb_bond()
      decapsulation occurs, so simply pass that original
      device into packet_type->func() as an argument.
      
      It remains to be seen whether we can use this same
      exact thing to get rid of skb->input_dev as well.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f2ccd8fa
  12. 22 Jun, 2005 2 commits
    • Shaun Pereira's avatar
      [X25]: Fast select with no restriction on response · ebc3f64b
      Shaun Pereira authored
      This patch is a follow up to patch 1 regarding "Selective Sub Address
      matching with call user data".  It allows use of the Fast-Select-Acceptance
      optional user facility for X.25.
      
      This patch just implements fast select with no restriction on response
      (NRR).  What this means (according to ITU-T Recomendation 10/96 section
      6.16) is that if in an incoming call packet, the relevant facility bits are
      set for fast-select-NRR, then the called DTE can issue a direct response to
      the incoming packet using a call-accepted packet that contains
      call-user-data.  This patch allows such a response.  
      
      The called DTE can also respond with a clear-request packet that contains
      call-user-data.  However, this feature is currently not implemented by the
      patch.
      
      How is Fast Select Acceptance used?
      By default, the system does not allow fast select acceptance (as before).
      To enable a response to fast select acceptance,  
      After a listen socket in created and bound as follows
      	socket(AF_X25, SOCK_SEQPACKET, 0);
      	bind(call_soc, (struct sockaddr *)&locl_addr, sizeof(locl_addr));
      but before a listen system call is made, the following ioctl should be used.
      	ioctl(call_soc,SIOCX25CALLACCPTAPPRV);
      Now the listen system call can be made
      	listen(call_soc, 4);
      After this, an incoming-call packet will be accepted, but no call-accepted 
      packet will be sent back until the following system call is made on the socket
      that accepts the call
      	ioctl(vc_soc,SIOCX25SENDCALLACCPT);
      The network (or cisco xot router used for testing here) will allow the 
      application server's call-user-data in the call-accepted packet, 
      provided the call-request was made with Fast-select NRR.
      Signed-off-by: default avatarShaun Pereira <spereira@tusc.com.au>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ebc3f64b
    • Shaun Pereira's avatar
      [X25]: Selective sub-address matching with call user data. · cb65d506
      Shaun Pereira authored
      From: Shaun Pereira <spereira@tusc.com.au>
      
      This is the first (independent of the second) patch of two that I am
      working on with x25 on linux (tested with xot on a cisco router).  Details
      are as follows.
      
      Current state of module:
      
      A server using the current implementation (2.6.11.7) of the x25 module will
      accept a call request/ incoming call packet at the listening x.25 address,
      from all callers to that address, as long as NO call user data is present
      in the packet header.
      
      If the server needs to choose to accept a particular call request/ incoming
      call packet arriving at its listening x25 address, then the kernel has to
      allow a match of call user data present in the call request packet with its
      own.  This is required when multiple servers listen at the same x25 address
      and device interface.  The kernel currently matches ALL call user data, if
      present.
      
      Current Changes:
      
      This patch is a follow up to the patch submitted previously by Andrew
      Hendry, and allows the user to selectively control the number of octets of
      call user data in the call request packet, that the kernel will match.  By
      default no call user data is matched, even if call user data is present. 
      To allow call user data matching, a cudmatchlength > 0 has to be passed
      into the kernel after which the passed number of octets will be matched. 
      Otherwise the kernel behavior is exactly as the original implementation.
      
      This patch also ensures that as is normally the case, no call user data
      will be present in the Call accepted / call connected packet sent back to
      the caller 
      
      Future Changes on next patch:
      
      There are cases however when call user data may be present in the call
      accepted packet.  According to the X.25 recommendation (ITU-T 10/96)
      section 5.2.3.2 call user data may be present in the call accepted packet
      provided the fast select facility is used.  My next patch will include this
      fast select utility and the ability to send up to 128 octets call user data
      in the call accepted packet provided the fast select facility is used.  I
      am currently testing this, again with xot on linux and cisco.  
      Signed-off-by: default avatarShaun Pereira <spereira@tusc.com.au>
      
      (With a fix from Alexey Dobriyan <adobriyan@gmail.com>)
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cb65d506
  13. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4