netdev - Re: [PATCH net-next 00/23] TIPC: Updates for what will be v3.3

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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAP=VYLpwswOktVAu1qp36KvKWKk1Shq+3Hamg4bmgkDxzArNEQ@mail.gmail.com>
Date:	Tue, 27 Dec 2011 21:16:10 -0500
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, allan.stephens@...driver.com,
	ying.xue@...driver.com
Subject: Re: [PATCH net-next 00/23] TIPC: Updates for what will be v3.3

On Tue, Dec 27, 2011 at 1:08 PM, David Miller <davem@...emloft.net> wrote:
> From: Paul Gortmaker <paul.gortmaker@...driver.com>
> Date: Tue, 27 Dec 2011 12:39:19 -0500
>
>> Here are some more updates for TIPC, based on the backlog of stuff
>> that was unfortunately stacked away in sourceforge a while ago.
>>
>> Given the timing, please feel free to defer these to the for-3.4
>> net-next if there isn't a convenient opportunity to process it
>> before 3.2 is officially released.  I can easily resend later.
>>
>> Fortunately, the SF backlog will finally be 100% gone with the
>> pending stuff that will be sent in the next year for the 3.4
>> net-next, so that will be nice to have that task closed out.
>>
>> I just finished testing this over the wire between an x86-32 and
>> an x86-64 box, with both taking turns being server and client.
>
> Pulled, thanks Paul.
>
> Two suggestions:
>
> 1) Please rename things like "struct media" to something more global
>   namespace friendly like "struct tipc_media"

Yep, I can do that easily, and probably send that out this week,
since a change like this won't invalidate any prev. testing etc.

>
> 2) We really should get rid of the ad-hoc debug logging facility tipc
>   uses.  It's not like there aren't tons of generic, well maintained,
>   feature-full logging facilities available.  There is no reason for
>   tipc to have it's own special, private, logginc facility.

Sounds like the right thing to do; I will take a look at this to see
how involved it is.  I don't think there should be any problem
getting it in with the remaining SF changes for 3.4 content in
the new year.

Thanks,
Paul.

>
>   If the generic facilities lack some feature, add it and submit
>   it for inclusion to linux-kernel so everyone can use it, not just
>   TIPC.
> --
> 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
--
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