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

[Sam Ravnborg <sam@ravnborg.org>]

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