linux-kernel - Re: [PATCH v2 03/13] backports: allow for different backport prefix

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: <CAB=NE6Wu7gFh+_1ebiaWCq2cUt_SnCMB-+1Xv9ZuZtBafdg0Vg@mail.gmail.com>
Date:	Wed, 5 Nov 2014 15:15:48 -0800
From:	"Luis R. Rodriguez" <mcgrof@...e.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Johannes Berg <johannes@...solutions.net>,
	"backports@...r.kernel.org" <backports@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Yann E. MORIN" <yann.morin.1998@...e.fr>,
	Michal Marek <mmarek@...e.cz>,
	Stefan Assmann <sassmann@...nic.de>
Subject: Re: [PATCH v2 03/13] backports: allow for different backport prefix

On Wed, Nov 5, 2014 at 3:09 PM, Andi Kleen <andi@...stfloor.org> wrote:
>> You know, this use case seems unavoidable so I'll just proceed with the
>> configurability of it. But note that it seems we're both in agreement
>> that right now what you described requires more work before in any way
>> shape or form folks start using it for the exact purpose you described.
>> I also think Andi Kleen's module namespace might be a much better solution to
>> that problem [0], we'd just have to carry the code ourselves as I am not
>
> Just to clarify. My name spaces didn't really provide different
> name spaces (like C++), it just added a ACL to exports to make it possible
> to do "export only to module N". But the name space itself
> was still flat

Indeed that is how I understood it and the use case in mind for
backporting different subsystems from different future versions of
Linux to an older one might be a use case here (although insane).

> On the linker side doing real name spaces is probably not too hard,
> but it would be difficult for linked in code without special linker
> support.

Good to know, perhaps useful for folks who really do consider
embarking on this strategy with backports (although I don't recommend
it).

>> sure if this is ever going to get upstream as it was originally nacked.
>
> May need to revisit that.

The only thing that was not clear to me from reviewing the module
namespace stuff a while ago was the original intent, but I confess I
actually only looked at the technical details to see if it was
applicable to the backports case, do you recall the original
motivation ?

 Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/