From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263345AbTKQGGw (ORCPT ); Mon, 17 Nov 2003 01:06:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263356AbTKQGFu (ORCPT ); Mon, 17 Nov 2003 01:05:50 -0500 Received: from dp.samba.org ([66.70.73.150]:64150 "EHLO lists.samba.org") by vger.kernel.org with ESMTP id S263345AbTKQGFn (ORCPT ); Mon, 17 Nov 2003 01:05:43 -0500 From: Rusty Russell To: Takashi Iwai Cc: linux-kernel@vger.kernel.org Subject: Re: modules.pnpmap output support In-reply-to: Your message of "Fri, 14 Nov 2003 15:07:03 BST." Date: Mon, 17 Nov 2003 14:46:16 +1100 Message-Id: <20031117060542.726CF2C31E@lists.samba.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In message you write: > Hi Rusty, Hi Takashi! > The attached patch makes depmod to output modules.pnpmap file > generated from the pnp device table. > > The output format is not compatible with the old modules.isapnpmap. > The new format shows the pnp id string (e.g. CTL0301) while the old > format uses the hex numbers. I don't think it's worthy to keep the > compatibility for this (since the new one is more intuitive), but it'd > be easy to follow the old style. That seems strange. If you don't worry about backwards compatibility, then the new scripts/file2alias.c approach is better, which generates aliases for each module (depmod then collects these into /lib/modules/`uname -r`/modules.alias for speed). The tables generated by depmod are purely for backwards compatibility, although it does look like they will be required throughout 2.6 at this stage. Does that clarify? Rusty. -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell.