netdev - Re: net: rtnetlink: support specifying device flags on device creation

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] [day] [month] [year] [list]

Message-ID: <4B8BDC27.2060803@trash.net>
Date:	Mon, 01 Mar 2010 16:24:23 +0100
From:	Patrick McHardy <kaber@...sh.net>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org
Subject: Re: net: rtnetlink: support specifying device flags on device creation

David Miller wrote:
> From: Patrick McHardy <kaber@...sh.net>
> Date: Fri, 26 Feb 2010 17:34:49 +0100 (MET)
> 
>> The following patches add support to specify the device flags (like UP) when
>> creating a new device through rtnl_link. This requires to surpress netlink
>> notifications until the device is fully configured in order to not confuse
>> userspace when changing the flags fails and registration has to be undone.
>> Once the device is configured, a single NEWLINK message with the full state
>> is sent.
>>
>> The individual patch changelogs describe the necessary changes in more detail.
> 
> All applied, but two things:
> 
> 1) This patch set was harder to review because there were no
>    default initializations of the new enumeration you added
>    to struct netdev.
> 
>    I know RTNL_LINK_INITIALIZED is probably zero by C enumeration
>    rules, and the zeroing out of new netdev objects gives us this,
>    but I only figured that out after some time.
> 
>    It deserved at least a commit message mention in patch #2.

Agreed. The reason to use the value 0 for RTNL_LINK_INITIALIZED
was that it avoids touching drivers that can register netdevices
through non rtnl_link paths, like bonding, ifb or dummy.

> 2) I would really appreciate you forming your patch postings
>    properly.  I have to edit them every single time
> 
>    You put the whole output of "git show" or "git format-patch" into
>    your email body.  That doesn't work, we don't want all of those
>    commit ID etc. lines in there.  It also causes every line of your
>    commit messages to be indented by 4 spaces.
> 
>    Your email body should just contain the unindented commit message
>    and the signoffs, then the patch itself.
> 
>    Your Subject lines are also not setup properly.  Because the
>    "net X/N:" thing isn't in [] brackets, it ends up in the
>    commit message header lines when I feed your emails to
>    "git am".
> 
>    All of this could be avoided if you used git send-email but
>    I realize that a lot of people dislike that for one reason
>    or another (myself included), but if you're going to compose
>    the emails by hand you ought to make it look the same (syntax
>    wise) as what git send-email would have emitted.

I'll either switch to git-send-email or make sure my script
works properly with git-am.
--
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