All of lore.kernel.org
 help / color / mirror / Atom feed
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: Fri, 07 Dec 2007 09:59:32 +0900	[thread overview]
Message-ID: <47589AF4.6080708@gmail.com> (raw)
In-Reply-To: <20071206223754.GB25209@uranus.ravnborg.org>

Sam Ravnborg wrote:
>> 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.
> 
> googled a bit.
> It looks like:
> awk '!x[$0]++'
> does the trick.

Great, that's much better.  I'll give it a try.

> So we can skip the C file (good thing).

Fully agreed.

>>> 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.
> With this change building modpost no longer worked so kbuild
> does not like the preceeding slashes. It could be fixed but thats
> another patch.

I don't really follow what you mean here.  Do you mean with the tailing
slash normalized, modpost doesn't work anymore?  Or with the
normalization removed?

>>> 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 guess modules can be built as modules - but they can never be built-in.
> And if someone uses subdir-y to point to a dir with modules
> I would anyway cosider that a bug.

s/module/component which can be a dynamically loadable module or
built-in to the kernel/ in my original sentence.  I just couldn't find a
good word to use.  So, you're saying subdir-ym's can be dropped from
modorder, right?  It would be great if we can implement a safeguard to
check that subdif-ym's don't actually contain modules.

Thanks.

-- 
tejun

  reply	other threads:[~2007-12-07  0:59 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
2007-12-06 22:37             ` Sam Ravnborg
2007-12-07  0:59               ` Tejun Heo [this message]
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=47589AF4.6080708@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.