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]
Date:	Fri, 23 Nov 2007 14:35:05 +1100
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Andi Kleen <ak@...e.de>
Cc:	Christoph Hellwig <hch@...radead.org>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, sam@...nborg.org
Subject: Re: [PATCH RFC] [1/9] Core module symbol namespaces code and intro.

On Friday 23 November 2007 12:36:22 Andi Kleen wrote:
> On Friday 23 November 2007 01:25, Rusty Russell wrote:
> > That's my point.  If there's a whole class of modules which can use a
> > symbol, why are we ruling out external modules?
>
> The point is to get cleaner interfaces.

But this doesn't change interfaces at all.  It makes modules fail to load 
unless they're on a permitted list, which now requires maintenance.

> Anything which is kind of internal 
> should only be used by closely related in tree modules which can be
> updated.

Is there evidence that this is a problem for us?  Are there any interfaces 
you've restricted so far which are causing problems?

> Point of is not to be some kind of license enforcer or similar, 
> there are already other mechanisms for that. Just to get the set of really
> public kernel interfaces down to a manageable level.

Why do we care what a "really public"?  We treat them all the same, as 
changeable interfaces.  ie.  None of them are "really public".

For example, you put all the udp functions in the "udp" namespace.  But what 
have we gained?  What has become easier to maintain?  All those function 
start with "udp_": are people having trouble telling what they're for?

If you really want to reduce "public interfaces" then it's much simpler to 
mark explicitly what out-of-tree modules can use.  We can have a list of 
symbol names in include/linux/public-exports.h.

I just don't see what problems this separation solves.
Rusty.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ