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

quoted text
> > > 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/