Corey Hickey wrote:
> Patrick McHardy wrote:
>
>>> +static void sfq_destroy(struct Qdisc *sch)
>>> +{
>>> +struct sfq_sched_data *q = qdisc_priv(sch);
>>> +sfq_q_destroy(q);
>>> +}
>>
>>
>> It does look pointless, after applying all patches sfq_destroy still
>> remains a simply wrapper aro
Patrick McHardy wrote:
Corey Hickey wrote:
The sfq_destroy() --> sfq_q_destroy() change looks pointless here,
but it's cleaner to split now and add code to sfq_q_destroy() in a
later patch.
+static void sfq_destroy(struct Qdisc *sch)
+{
+ struct sfq_sched_data *q = qdisc_priv(sch);
+
Corey Hickey wrote:
> The sfq_destroy() --> sfq_q_destroy() change looks pointless here,
> but it's cleaner to split now and add code to sfq_q_destroy() in a
> later patch.
>
> +static void sfq_destroy(struct Qdisc *sch)
> +{
> + struct sfq_sched_data *q = qdisc_priv(sch);
> + sfq_q_destro
Factor code out of sfq_init() and sfq_destroy(), again so that the
new functions can be used by sfq_change() later.
Actually, as the diff itself shows, most of the sfq_q_init() code
comes from the original sfq_change(), but sfq_change() is only
called by sfq_init() right now. Thus, it is safe to r
Factor code out of sfq_init() and sfq_destroy(), again so that the
new functions can be used by sfq_change() later.
Actually, as the diff itself shows, most of the sfq_q_init() code
comes from the original sfq_change(), but sfq_change() is only
called by sfq_init() right now. Thus, it is safe to r
