1. 23 Jun, 2005 37 commits
  2. 22 Jun, 2005 3 commits
    • Nishanth Aravamudan's avatar
      [LTPC]: Replace schedule_timeout() with ssleep()/msleep() · 2c4ee8f9
      Nishanth Aravamudan authored
      
      
      Use ssleep() / msleep() [as appropriate]
      instead of schedule_timeout() to guarantee the task delays as expected.
      
      Signed-off-by: default avatarNishanth Aravamudan <nacc@us.ibm.com>
      Acked-by: default avatarArnaldo Carvalho de Melo <acme@conectiva.com.br>
      Signed-off-by: default avatarMaximilian Attems <janitor@sternwelten.at>
      Signed-off-by: default avatarDomen Puncer <domen@coderock.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2c4ee8f9
    • 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