linux-kernel - Re: [patch 4/4] Markers Support for Proprierary Modules

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:	Thu, 20 Mar 2008 23:15:35 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Jon Masters <jcm@...hat.com>
Cc:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Jon Masters <jcm@...masters.org>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Christoph Hellwig <hch@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [patch 4/4] Markers Support for Proprierary Modules


* Jon Masters <jcm@...hat.com> wrote:

> > > There seems to be good arguments for markers to support 
> > > proprierary modules. So I am throwing this one-liner in and let's 
> > > see how people react. [...]
> > 
> > ugh, this is unbelievably stupid move technically - so a very strong 
> > NACK. Allowing marker use in unfixable modules (today it's placing 
> > markers into unfixable modules, tomorrow it's marker use by such 
> > modules) has only one clear and predictable effect: it turns marker 
> > calls into essential ABIs because when faced with any breakage in an 
> > unfixable module that makes use of a marker in some kernel subsystem 
> > then all the pressure is on those who _can_ fix their code - meaning 
> > the kernel subsystem maintainers that use markers.
> 
> Mathieu's previous comment was that this was to help improve the 
> quality of such drivers. Out of interest, why do you dislike markers 
> so much?

i'm not particularly interested in improving the quality of such 
drivers. I'm interested in improving the quality of _open_ code. And not 
making too many promises in advance about how our kernel internals will 
look like in the future is a fundamental aspect of that.

So i have no problems with export trivial or cast-into-stone aspects of 
the kernel - doing that simply has no negative effects on open code. But 
the details of markers are far from settled and far from trivial.

	Ingo
--
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/