From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from srv5.dvmed.net ([207.36.208.214]:56039 "EHLO mail.dvmed.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754843AbYBLQYS (ORCPT ); Tue, 12 Feb 2008 11:24:18 -0500 Message-ID: <47B1C829.8020800@garzik.org> Date: Tue, 12 Feb 2008 11:24:09 -0500 From: Jeff Garzik MIME-Version: 1.0 Subject: multiple drivers, single device (was Re: Announce: Linux-next (Or Andrew's dream :-))) References: <20080212120208.f7168a91.sfr@canb.auug.org.au> <20080212042133.GA4625@kroah.com> In-Reply-To: <20080212042133.GA4625@kroah.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: Greg KH Cc: Stephen Rothwell , LKML , linux-next@vger.kernel.org, linux-arch@vger.kernel.org, Andrew Morton , Linus Greg KH wrote: > [1] Hopefully the "multiple drivers for a single device" feature people > have been asking for for years will be landing soon, of course the > number of odd places in the kernel that made the assumption that we > could only have one driver per device is causing lots of fun... Color me a bit skeptical... we've always had this capability really: for multi-function devices, just register as many subsystems as you need. If your device is a network _and_ SCSI device, you can do that with today's APIs. I just went through a long thread (e1000/e1000e) explaining how much pain multiple drivers for the same PCI ID cause on the distro side of things... its a mess. In each case you must write special case code to resolve the ambiguity. You never know which is the best driver to choose, or proper module load order -- which may vary depending on machine, not just static information captured from a kernel Makefile. Jeff