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: <20071207051420.GA27989@uranus.ravnborg.org>
Date:	Fri, 7 Dec 2007 06:14:20 +0100
From:	Sam Ravnborg <sam@...nborg.org>
To:	Tejun Heo <htejun@...il.com>
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

> 
> >>> 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?
I a mrproper tree I did:
make defconfig
make

And it failed because modpost were never built - because the directory
scripts/mod/ was never visited.

> 
> >>> 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?
Correct - my patch did so.

> It would be great if we can implement a safeguard to
> check that subdif-ym's don't actually contain modules.
Could be a good idea - will think about it.

	Sam
--
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/