~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~ [ freetext search ] ~ [ file search ] ~

Linux Cross Reference
Linux/net/802/TODO

Version: ~ [ 2.4.0 ] ~
Architecture: ~ [ i386 ] ~ [ alpha ] ~ [ m68k ] ~ [ mips ] ~ [ ppc ] ~ [ sparc ] ~ [ sparc64 ] ~

  1 Remaining Problems:
  2 
  3 1. Serialization of access to variables in the llc structure
  4 by mac_data_indicate(), timer expired functions, and data_request() .
  5 There is not serialization of any kind right now.
  6 While testing, I have not seen any problems that stem from this lack of
  7 serialization, but it wories me...
  8 
  9 2. The code is currently able to handle one connection only,
 10 there is more work in register_cl2llc_client() to make a chain
 11 of llc structures and in mac_data_indicate() to find back
 12 the llc structure addressed by an incomming frame.
 13 According to IEEE, connections are identified by (remote mac + local mac
 14 + dsap + ssap). dsap and ssap do not seem important: existing applications
 15 always use the same dsap/ssap. Its probably sufficient to index on 
 16 the remote mac only. 
 17  
 18 3. There is no test to see if the transmit window is full in data_request()
 19 as described in the doc p73, "7.5.1 Sending I PDUs" 3th alinea.
 20 The pdus presented to data_request() could probably go on the 
 21 awaiting-transmit-queue (atq). The real difficulty is coding a test
 22 to see if the transmit window is used up and to send the queue
 23 when space in the window becomes available.
 24 As I have no network layer that can generate a continous flow of pdus it is
 25 difficult to simulate a remote busy condition and hence to test the code
 26 to handle it.
 27  
 28 4. A simple flow control algorithm, steering the size of the transmit
 29 window would be nice to have.

~ [ source navigation ] ~ [ diff markup ] ~ [ identifier search ] ~ [ freetext search ] ~ [ file search ] ~

This page was automatically generated by the LXR engine.
Visit the LXR main site for more information.