netdev - Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 17 Apr 2008 20:03:04 +0200
From:	Tomasz Grobelny <tomasz@...belny.oswiecenia.net>
To:	Gerrit Renker <gerrit@....abdn.ac.uk>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	dccp@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [DCCP] [RFC] [Patchv2 1/1]: Queuing policies -- reworked version of Tomasz's patch set

Dnia Wednesday 16 of April 2008, Gerrit Renker napisał:
> 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).
>
The next paragraph was in fact about void* pointers. But the paragraph I 
quoted above talks only about whether those three values (policy 
numer/pointer, tx_qlen and possibly other data) should be put directly in 
struct dccp_sock or grouped in stuct queueing_policy which in turn should be 
one field in struct dccp_sock. In the mail from 18/03/2008 you seemed to be 
in favour of grouping, in the one from 15/04/2008 you seemed to contradict 
your earlier statement. At least that's how I understood it.
But never mind, both ways are ok for me.
-- 
Regards,
Tomasz Grobelny
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html