From: Jon M. <jon...@er...> - 2005-04-30 21:37:52
|
I think the ambition should be to get rid of the tipc_sock structure altogether, and I think that is possible. See below. /jon Walsh, Benjamin wrote: > Hello all, > > Here's a first pass about what has to be done for trimming the struct > tipc_sock structure, with much input from Al. > > 1) Add a back pointer in the 'tipc_sock' structure to either the 'struct > sock' or 'struct socket' parent. This is needed to access the 'wait' > queue in the socket structure, and the 'sk_receive_queue' by routines > that receive a 'struct tipc_sock *' in parameter and no 'struct socket > *'. Some of the routines in socket.c that are callbacks and thus called > from other modules are the problematic ones. > 1)Let "usr_handle" in tipc_port, which now points back to tipc_sock, point to struct sock instead. 2) Let sock->sk_protinfo point to the corresponding tipc_port. > 2) Remove the 'waitqueue' and use the one provided by > 'socket.wait'/'sock.sk_sleep' instead. It doesn't seem to be currently > used for anything in the tipc code. > good > 3) Remove 'no_block' and use the backpointer from the socket to the file > it is associated with to set/peek at the 'flags' field in the 'file' > structure. > good > 4) pollmask: not sure, any ideas? > Remove. Caclulate pollmask on-the-fly in poll(). This will become much simpler now that we remove the subscription/event stuff. The TIPC_TOPOLOGY_EVENT bit will go away,as will all the redundant poll bit combinations (TIPC_MSG_PENDING etc) defined in tipc.h. > 5) The 3 queue fields ('queue_size', 'queue_head', 'queue_tail') can be > all merged and use the 'sk_receive_queue' field in 'struct sock': > skb_xxx routines can then be used to manipulate the queue, and obtaining > the tail and the lenght. > good > 6) sub_list: not sure, any ideas? > Remove. I have a completely differrent solution to this, which does not involve socket.c at all. > 7) 'sem' mutex has to stay, unless we can somehow use the sk_lock field > for mutual exclusion. Any input on this? > It should be possible to use lock_sock() /release_sock(), i.e. the lock that is already available in struct sock. Use at the same places as we use the semaphore now, and we should be fine. > 8) Events stuff, will stay for the time being, but will probably go away > as it is reworked. > See above. > 9) 'type' field: already duplicated twice in 'struct socket' and 'struct > sock': get rid of and use one of these. > good > 10) 'sent_setup': could use the 'sk_state' field as it seems to be > currently used only by TCP. We would need a new definition for > TIPC_SYN_SENT (or something like that). > ok > 11) 'recv' field might have to stay; there doesn't seem to be a free > counter in the parent structures. > Add to struct tipc_port if nothing else can be found. > 12) 'dest': used for TIPC_GET_DEST_ADDR ioctl() (or its replacement); > might go away, look for a future email from Al concerning this. > ok > 13) 'ack_timeout': is it possible to use the 'sk_rcvtimeo' field in > 'struct sock', or will they clash? > let's hope so. > 14) The STREAM-only fields Might not be of any use anymore when the > (struct sk_buff).data pointer will be adjusted to the start of the data > portion of the message, and not the tipc header. The pointers in the > tipc_sock are only useful if we are reading in the middle of the > skbuff's data, so they can be per-skbuff, as they are reset as we move > down the skbuff chain: there doesn't seem to be a need to keep them > after a message is exhausted and we move to the next. Another solution > that is per-skbuff could be to use the cb[40] field in 'struct sk_buff'. > Sounds good. > Any NO-NOs in there? Suggestions? Comments? > > Thanks, > Ben > |