Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757869AbYCTTNI (ORCPT ); Thu, 20 Mar 2008 15:13:08 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756887AbYCTTM6 (ORCPT ); Thu, 20 Mar 2008 15:12:58 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:42751 "EHLO mx2.mail.elte.hu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757019AbYCTTM5 (ORCPT ); Thu, 20 Mar 2008 15:12:57 -0400 Date: Thu, 20 Mar 2008 20:12:05 +0100 From: Ingo Molnar To: Mathieu Desnoyers Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Jon Masters , "Frank Ch. Eigler" , Jon Masters , Rusty Russell , Christoph Hellwig , Linus Torvalds Subject: Re: [patch 4/4] Markers Support for Proprierary Modules Message-ID: <20080320191205.GA13309@elte.hu> References: <20080320002737.918213455@polymtl.ca> <20080320002835.384758480@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080320002835.384758480@polymtl.ca> User-Agent: Mutt/1.5.17 (2007-11-01) X-ELTE-VirusStatus: clean X-ELTE-SpamScore: -1.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.5 required=5.9 tests=BAYES_00 autolearn=no SpamAssassin version=3.2.3 -1.5 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1388 Lines: 30 * Mathieu Desnoyers 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. unfixable modules should only be allowed access to easy things they can access anyway, or to such fundamental things which we wont realistically change anyway. Markers are neither. (i also find it puzzling why you go out on a limb helping a piece of _irrelevant_ technology that has been the unparalleled source of pain and anguish to both kernel users and kernel developers.) Ingo -- 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/