From: Tejun Heo <htejun@gmail.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
notting@redhat.com, rusty@rustcorp.com.au, kay.sievers@vrfy.org,
greg@kroah.com
Subject: Re: [PATCH] depmod: sort output according to modules.order
Date: Thu, 06 Dec 2007 08:28:03 +0900 [thread overview]
Message-ID: <47573403.1060203@gmail.com> (raw)
In-Reply-To: <20071205190609.GA14997@uranus.ravnborg.org>
Sam Ravnborg wrote:
> On Wed, Dec 05, 2007 at 04:34:30PM +0900, Tejun Heo wrote:
>> Tejun Heo wrote:
>>>> It would also simplify the kbuild integration if depmod
>>>> could read the modules as a space separated list where
>>>> duplicates are allowed.
>>>> If we do so then the is no reason to escape to the shell
>>>> in Makeilfe.build and we do not have to remove duplicates either.
>>> I'm no Makefile expert so no doubt my modifications are ugly. But I
>>> think producing a file w/ duplicates in it is just ugly.
>> Oh, and, depmod should do just fine with duplicate entries as it is.
> What is the purpose of REMOVE-DUP then?
> If depmod handle duplicate entries there is no need to remove them.
As I said, I don't think leaving duplicate lines in a file which will be
installed, distributed and used widely is the RTTD. There can be other
uses of the file. For example, the file can be parsed and modified by
distro specific module selector. Sure, all of them can be made to deal
with dup entries but that's just not the right place to solve the problem.
> And this change in Makefile.lib seems bogus:
> +# make sure '/' follows subdirs
> +subdir-y := $(patsubst %//,%/, $(addsuffix, /,$subdir-y))
> +subdir-m := $(patsubst %//,%/, $(addsuffix, /,$subdir-m))
Some subdir-y|m entries have following / while others don't. subdir-y|m
are lax about because either way it points to subdirectory. The above
two lines are to normalize them so that there's no surprises when
concatenating file name to it. I think it's a good idea to have the
above with or without other changes.
> I commented it out and with my config everything seems to still
> work as expected.
Yeah, it depends on config. If you don't have subdir-y|m entries which
don't have following '/', it will work just fine. If you do, it will break.
> And I get scripts/mod/modpost built in a mrproper tree again (bug!).
This I dunno much about.
> subdir-y and subdir-m does not point to directories that
> contains modules (built-in or not) so they can be ignored for modorder.
I didn't know that. Is it forced that modules can't be put in
subdir-y|m directories? What happens if I do that?
> I did a quick hack up top of your patch and came up with the following.
> I just checked that if I manually ran remove-dup then the resulting
> module.order files were identical with a simple configuration (50 modules).
e.g. Some of USB modules are listed twice in config. They'll appear twice.
> And I did not try out depmod at all.
> Feel free to use this as an updated patch.
Ah.. that looks much less hacky. Thanks. I'll submit an updated
version as soon as above issues are settled.
Thanks.
--
tejun
next prev parent reply other threads:[~2007-12-05 23:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-12-04 13:49 [PATCH] kbuild: implement modules.order Tejun Heo
2007-12-04 13:55 ` [PATCH] depmod: sort output according to modules.order Tejun Heo
2007-12-05 7:25 ` Sam Ravnborg
2007-12-05 7:33 ` Tejun Heo
2007-12-05 7:34 ` Tejun Heo
2007-12-05 19:06 ` Sam Ravnborg
2007-12-05 23:28 ` Tejun Heo [this message]
2007-12-06 22:37 ` Sam Ravnborg
2007-12-07 0:59 ` Tejun Heo
2007-12-07 5:14 ` Sam Ravnborg
2007-12-08 8:09 ` Jon Masters
2007-12-08 12:39 ` Alan Cox
2007-12-08 8:03 ` Jon Masters
2007-12-08 8:19 ` Jon Masters
2007-12-09 5:48 ` Tejun Heo
2007-12-04 15:07 ` [PATCH] kbuild: implement modules.order WANG Cong
2007-12-04 15:21 ` Tejun Heo
2007-12-05 7:01 ` WANG Cong
2007-12-05 7:11 ` Tejun Heo
2007-12-05 7:22 ` Li Zefan
2007-12-06 3:02 ` Rusty Russell
2007-12-07 17:48 ` Adrian Bunk
2007-12-07 23:59 ` Tejun Heo
2007-12-08 14:28 ` Adrian Bunk
2007-12-09 5:44 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47573403.1060203@gmail.com \
--to=htejun@gmail.com \
--cc=greg@kroah.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=notting@redhat.com \
--cc=rusty@rustcorp.com.au \
--cc=sam@ravnborg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox