From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030817AbWLPJFu (ORCPT ); Sat, 16 Dec 2006 04:05:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030821AbWLPJFt (ORCPT ); Sat, 16 Dec 2006 04:05:49 -0500 Received: from gprs189-60.eurotel.cz ([160.218.189.60]:4126 "EHLO spitz.ucw.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1030817AbWLPJFs (ORCPT ); Sat, 16 Dec 2006 04:05:48 -0500 Date: Sat, 16 Dec 2006 09:05:32 +0000 From: Pavel Machek To: Linus Torvalds Cc: "Michael K. Edwards" , Greg KH , Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [GIT PATCH] more Driver core patches for 2.6.19 Message-ID: <20061216090532.GF4049@ucw.cz> References: <20061213195226.GA6736@kroah.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Hi! > > Seriously, though, please please pretty please do not allow a facility > > for "going through a simple interface to get accesses to irqs and > > memory regions" into the mainline kernel, with or without toy ISA > > examples. > > I do agree. > > I'm not violently opposed to something like this in practice (we've > already allowed it for USB devices), but there definitely needs to be a > real reason that helps _us_, not just some ass-hat vendor that looks for a > way to avoid open-sourcing their driver. > > If there are real and valid uses (and as mentioned, I actually think that > the whole graphics-3D-engine-thing is such a use) where a kernel driver > simply doesn't work out well, or where there are serious tecnical reasons > why it wants to be in user space (and "stability" is not one such thing: > if you access hardware directly in user space, and your driver is buggy, > the machine is equally deal, and a hell of a lot harder to control to > boot). Well.. it is easier to debug in userspace. While bad hw access can still kill the box, bad free() will not, and most bugs in early developent are actually of 2nd kind. Pavel -- Thanks for all the (sleeping) penguins.