1. 24 6月, 2005 3 次提交
  2. 23 6月, 2005 2 次提交
    • S
      [X25]: Fast select with no restriction on response · ebc3f64b
      Shaun Pereira 提交于
      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: NShaun Pereira <spereira@tusc.com.au>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ebc3f64b
    • S
      [X25]: Selective sub-address matching with call user data. · cb65d506
      Shaun Pereira 提交于
      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: NShaun Pereira <spereira@tusc.com.au>
      
      (With a fix from Alexey Dobriyan <adobriyan@gmail.com>)
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb65d506
  3. 22 6月, 2005 2 次提交
    • I
      [PATCH] smp_processor_id() cleanup · 39c715b7
      Ingo Molnar 提交于
      This patch implements a number of smp_processor_id() cleanup ideas that
      Arjan van de Ven and I came up with.
      
      The previous __smp_processor_id/_smp_processor_id/smp_processor_id API
      spaghetti was hard to follow both on the implementational and on the
      usage side.
      
      Some of the complexity arose from picking wrong names, some of the
      complexity comes from the fact that not all architectures defined
      __smp_processor_id.
      
      In the new code, there are two externally visible symbols:
      
       - smp_processor_id(): debug variant.
      
       - raw_smp_processor_id(): nondebug variant. Replaces all existing
         uses of _smp_processor_id() and __smp_processor_id(). Defined
         by every SMP architecture in include/asm-*/smp.h.
      
      There is one new internal symbol, dependent on DEBUG_PREEMPT:
      
       - debug_smp_processor_id(): internal debug variant, mapped to
                                   smp_processor_id().
      
      Also, i moved debug_smp_processor_id() from lib/kernel_lock.c into a new
      lib/smp_processor_id.c file.  All related comments got updated and/or
      clarified.
      
      I have build/boot tested the following 8 .config combinations on x86:
      
       {SMP,UP} x {PREEMPT,!PREEMPT} x {DEBUG_PREEMPT,!DEBUG_PREEMPT}
      
      I have also build/boot tested x64 on UP/PREEMPT/DEBUG_PREEMPT.  (Other
      architectures are untested, but should work just fine.)
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NArjan van de Ven <arjan@infradead.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      39c715b7
    • J
      [IPV6]: V6 route events reported with wrong netlink PID and seq number · 0d51aa80
      Jamal Hadi Salim 提交于
      Essentially netlink at the moment always reports a pid and sequence of 0
      always for v6 route activities. 
      To understand the repurcassions of this look at:
      http://lists.quagga.net/pipermail/quagga-dev/2005-June/003507.html
      
      While fixing this, i took the liberty to resolve the outstanding issue
      of IPV6 routes inserted via ioctls to have the correct pids as well.
      
      This patch tries to behave as close as possible to the v4 routes i.e
      maintains whatever PID the socket issuing the command owns as opposed to
      the process. That made the patch a little bulky.
      
      I have tested against both netlink derived utility to add/del routes as
      well as ioctl derived one. The Quagga folks have tested against quagga.
      This fixes the problem and so far hasnt been detected to introduce any
      new issues.
      Signed-off-by: NJamal Hadi Salim <hadi@cyberus.ca>
      Acked-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d51aa80
  4. 21 6月, 2005 5 次提交
  5. 19 6月, 2005 12 次提交
  6. 14 6月, 2005 1 次提交
  7. 30 5月, 2005 1 次提交
  8. 27 5月, 2005 1 次提交
  9. 20 5月, 2005 1 次提交
  10. 06 5月, 2005 2 次提交
  11. 04 5月, 2005 4 次提交
  12. 01 5月, 2005 2 次提交
    • M
      [PATCH] DocBook: fix some descriptions · 67be2dd1
      Martin Waitz 提交于
      Some KernelDoc descriptions are updated to match the current code.
      No code changes.
      Signed-off-by: NMartin Waitz <tali@admingilde.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      67be2dd1
    • P
      [PATCH] DocBook: changes and extensions to the kernel documentation · 4dc3b16b
      Pavel Pisa 提交于
      I have recompiled Linux kernel 2.6.11.5 documentation for me and our
      university students again.  The documentation could be extended for more
      sources which are equipped by structured comments for recent 2.6 kernels.  I
      have tried to proceed with that task.  I have done that more times from 2.6.0
      time and it gets boring to do same changes again and again.  Linux kernel
      compiles after changes for i386 and ARM targets.  I have added references to
      some more files into kernel-api book, I have added some section names as well.
       So please, check that changes do not break something and that categories are
      not too much skewed.
      
      I have changed kernel-doc to accept "fastcall" and "asmlinkage" words reserved
      by kernel convention.  Most of the other changes are modifications in the
      comments to make kernel-doc happy, accept some parameters description and do
      not bail out on errors.  Changed <pid> to @pid in the description, moved some
      #ifdef before comments to correct function to comments bindings, etc.
      
      You can see result of the modified documentation build at
        http://cmp.felk.cvut.cz/~pisa/linux/lkdb-2.6.11.tar.gz
      
      Some more sources are ready to be included into kernel-doc generated
      documentation.  Sources has been added into kernel-api for now.  Some more
      section names added and probably some more chaos introduced as result of quick
      cleanup work.
      Signed-off-by: NPavel Pisa <pisa@cmp.felk.cvut.cz>
      Signed-off-by: NMartin Waitz <tali@admingilde.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      4dc3b16b
  13. 29 4月, 2005 3 次提交
  14. 25 4月, 2005 1 次提交
    • H
      [SELINUX]: Fix ipv6_skip_exthdr() invocation causing OOPS. · 0d3d077c
      Herbert Xu 提交于
      The SELinux hooks invoke ipv6_skip_exthdr() with an incorrect
      length final argument.  However, the length argument turns out
      to be superfluous.
      
      I was just reading ipv6_skip_exthdr and it occured to me that we can
      get rid of len altogether.  The only place where len is used is to
      check whether the skb has two bytes for ipv6_opt_hdr.  This check
      is done by skb_header_pointer/skb_copy_bits anyway.
      
      Now it might appear that we've made the code slower by deferring
      the check to skb_copy_bits.  However, this check should not trigger
      in the common case so this is OK.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0d3d077c