From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner+willy=40w.ods.org@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S263466AbTKQLUF (ORCPT <rfc822;willy@w.ods.org>);
	Mon, 17 Nov 2003 06:20:05 -0500
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263467AbTKQLUF
	(ORCPT <rfc822;linux-kernel-outgoing>);
	Mon, 17 Nov 2003 06:20:05 -0500
Received: from ns.suse.de ([195.135.220.2]:30166 "EHLO Cantor.suse.de")
	by vger.kernel.org with ESMTP id S263466AbTKQLUB (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 17 Nov 2003 06:20:01 -0500
Date: Mon, 17 Nov 2003 12:19:59 +0100
Message-ID: <s5hu153jl7k.wl@alsa2.suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: modules.pnpmap output support 
In-Reply-To: <20031117060542.726CF2C31E@lists.samba.org>
References: <s5hekwbjb7c.wl@alsa2.suse.de>
	<20031117060542.726CF2C31E@lists.samba.org>
User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 MULE XEmacs/21.4 (patch 13) (Rational FORTRAN) (i386-suse-linux)
MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
X-Mailing-List: linux-kernel@vger.kernel.org

At Mon, 17 Nov 2003 14:46:16 +1100,
Rusty Russell wrote:
> 
> In message <s5hekwbjb7c.wl@alsa2.suse.de> 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?

ah, ok, that makes sense.

but still, file2alias (as of test9) doesn't output the entries for pnp
devices...


Takashi