netdev - Re: [PATCH 1/7] Preparatory refactoring part 1.

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]

Message-ID: <46AF1303.4040909@trash.net>
Date:	Tue, 31 Jul 2007 12:46:27 +0200
From:	Patrick McHardy <kaber@...sh.net>
To:	Corey Hickey <bugfood-ml@...ooh.org>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH 1/7] Preparatory refactoring part 1.

Corey Hickey wrote:
> Patrick McHardy wrote:
> 
>>> -static int
>>> -sfq_enqueue(struct sk_buff *skb, struct Qdisc* sch)
>>> +static void sfq_q_enqueue(struct sk_buff *skb, struct sfq_sched_data
>>> *q, unsigned int end)
>>
>>
>>
>> Please make sure to break at 80 chars and to keep the style
>> in this file consistent (newline before function name).
> 
> 
> Ok. For what it's worth, though, most of the original functions in the
> file don't have a newline before the function name. Omitting the newline
>  would thus make the new/changed functions more consistent with the rest
> of the file. I don't have a preference either way, so unless you change
> your mind I'll put the newline back in..

You're right, just keep it consistent please and break at 80 chars.

>>> -    sch->qstats.backlog += skb->len;
>>
>>
>> Why not keep this instead of having both callers do it?
> 
> 
> My idea was to have all the sfq_q_* functions operate on "struct
> sfq_sched_data" and have no knowledge of the "struct Qdisc". I did this
> in order to be able to use the new functions in sfq_change() when the
> temporary sfq_sched_data doesn't have a parent Qdisc.
> 
> There's probably a better way, and I am of course open to suggestions,
> but what I did made sense to me.

Also sounds fine.
-
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