Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 25 Nov 2002 16:36:42 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 25 Nov 2002 16:36:42 -0500 Received: from 12-231-249-244.client.attbi.com ([12.231.249.244]:22031 "HELO kroah.com") by vger.kernel.org with SMTP id ; Mon, 25 Nov 2002 16:36:41 -0500 Date: Mon, 25 Nov 2002 13:36:17 -0800 From: Greg KH To: Rusty Russell Cc: linux-kernel@vger.kernel.org, Kai Germaschewski , perex@suse.cz Subject: Re: [PATCH] Module alias and table support Message-ID: <20021125213617.GA25269@kroah.com> References: <20021120082330.GD22408@kroah.com> <20021125003005.2AB4B2C0BF@lists.samba.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021125003005.2AB4B2C0BF@lists.samba.org> User-Agent: Mutt/1.4i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2455 Lines: 59 On Mon, Nov 25, 2002 at 10:34:16AM +1100, Rusty Russell wrote: > > > + /* not matched against */ > > > + kernel_long driver_info; > > > > Or is it because of "kernel_long"? I'm pretty sure this field is only > > used within the kernel, and userspace does not care at all about it. > > It sucks to reproduce this, yes. But you need to know the size of the > structure to grab it out of the object file. At least this way it's > in the kernel source where we can change it. But can't we still just use the structure from the kernel header and not have to retype it here? If needed, we can change the type of driver_info into something more portable than what it is today. That would be much easier in the long run. > > Why are you doing this "preprocessing" of the flags and the different > > fields? If you do this, you mess with the logic of the current > > /sbin/hotplug tools a lot, as they expect to have to do this. > > The plan was that /sbin/hotplug will gather all the fields for > whatever device has been inserted and create the modprobe string, eg: > > system("modprobe usb:v0506p4601dl01dh01dc01dsc01dp01ic01isc01ip01"); > > Which will simply match the alias such as: > usb:v0506p4601dl*dh*dc*dsc*dp*ic*isc*ip* Ah, you never told me about this plan :) Yes, that would be very nice to have, pushing the logic out of the /sbin/hotplug code and into modprobe doesn't bother me. That just saved a _whole_ bunch of space in diethotplug, so you've made up for making the size smaller. How would modprobe know which driver to load based on the above line? Are you going to scan all module files, or rely on something like the modules.*map files of today? > > Also realize that if you do this, you can't generate the existing > > modules.*map files from the exported values. > > Hmm, I thought about enhancing this code to generate the .map > files as well (where it has all the information). BTW, did I break > the current depmod map-generating code? I don't know, I haven't looked into that. Just realize that if you pre-process the information like you are proposing to do, you can't get it back later, which changes the way things work. thanks, greg k-h - 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/