Quoting Tomasz Grobelny:
| Dnia Tuesday 15 of April 2008, Gerrit Renker napisa?:
| > | > @@ -501,6 +519,8 @@ struct dccp_sock {
| > | > struct ccid *dccps_hc_rx_ccid;
| > | > struct ccid *dccps_hc_tx_ccid;
| > | > struct dccp_options_received dccps_options_received;
| > | > + __u8 dccps_qpolicy;
| > | > + __u32 dccps_tx_qlen;
| > | > enum dccp_role dccps_role:2;
| > | > __u8 dccps_hc_rx_insert_options:1;
| > | > __u8 dccps_hc_tx_insert_options:1;
| > |
| > | I know that currently none of the policies has any per-socket data. But
| > | if it had were should it go?
| >
| > I can't see anything wrong with putting everything into dccp_sock. To do it
| > well, we could consider inserting documentation such as "this section is
| > only for queueing policies" (as is done very well for struct tcp_sock).
| >
| Let me remind you your comment made on 18/03/2008 on dccp ml to my first
| patch:
| --- START ---
| @@ -545,6 +549,8 @@ struct dccp_sock {
| __u8 dccps_hc_tx_insert_options:1;
| __u8 dccps_server_timewait:1;
| struct timer_list dccps_xmit_timer;
| + struct queuing_policy *dccps_policy;
| + void *dccps_policy_data;
| };
|
| I think this should be just one field for the policy, and the
| policy_data can be an internal field of `struct queueing_policy'
| (compare with struct ackvec or struct ccid).
| --- END ---
|
Hm, even after reading it again I still find that I don't like void* fields. It
may be a personal thing, but I think using void* as part of a field is bad (and
this was in an even earlier comment).
I think I understand your approach better now, after going through the
patches again.
| Ok, you are right. If before DCCP_LISTENING there is always DCCP_CLOSED then
| there is no need to allow changing qpolicy in DCCP_LISTENING state.
|
Yes, that's right -- the initial state is always DCCP_CLOSED, set in
dccp_init_sock().
The University of Aberdeen is a charity registered in Scotland, No SC013683.
--
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
