linux-kernel - Re: [PATCH] depmod: sort output according to modules.order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47573403.1060203@gmail.com>
Date:	Thu, 06 Dec 2007 08:28:03 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Sam Ravnborg <sam@...nborg.org>
CC:	Linux Kernel <linux-kernel@...r.kernel.org>, notting@...hat.com,
	rusty@...tcorp.com.au, kay.sievers@...y.org, greg@...ah.com
Subject: Re: [PATCH] depmod: sort output according to modules.order

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/