Re: [PATCH] depmod: sort output according to modules.order, take #2
On Thu, 2008-01-03 at 10:12 +1100, Rusty Russell wrote: > Oh, sorry. Jon is now module-init-tools maintainer, and I've cc'd him and > forwarded your original patch. Ta. I was semi-offline last week due to holidays, but already saw the original mail and have another fix for debug sections - will sort it. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order, take #2
On Wednesday 02 January 2008 22:13:52 Tejun Heo wrote:
> Tejun Heo wrote:
> > Tejun Heo wrote:
> >> Kbuild now generates and installs modules.order along with modules.
> >> This patch updates depmod such that it sorts module list according to
> >> the file before generating output files. Modules which aren't on
> >> modules.order are put after modules which are ordered by
> >> modules.order.
> >>
> >> This makes modprobe to prioritize modules according to kernel
> >> Makefile's just as built-in modules are link-ordered by them.
> >>
> > The kernel part is in now. Rusty Russell, what do you think about this
> > depmod change?
>
> Ping?
Oh, sorry. Jon is now module-init-tools maintainer, and I've cc'd him and
forwarded your original patch.
Thanks,
Rusty.
--- Begin Message ---
Kbuild now generates and installs modules.order along with modules.
This patch updates depmod such that it sorts module list according to
the file before generating output files. Modules which aren't on
modules.order are put after modules which are ordered by
modules.order.
This makes modprobe to prioritize modules according to kernel
Makefile's just as built-in modules are link-ordered by them.
This patch is against module-init-tools 3.3-pre1.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Cc: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Bill Nottingham <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
Cc: Greg Kroah-Hartman <[EMAIL PROTECTED]>
Cc: Kay Sievers <[EMAIL PROTECTED]>
---
Comment added and path comparion logic slightly modified such that
dirname part of mode->pathname is ignored instead of prepending
dirname to lines read from modules.order. Behavior-wise it's
identical to the previous version.
Thanks.
depmod.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/depmod.c b/depmod.c
index ea7ad05..c3ae5a2 100644
--- a/depmod.c
+++ b/depmod.c
@@ -585,6 +585,54 @@ static struct module *grab_basedir(const char *dirname)
return list;
}
+static void sort_modules(const char *dirname, struct module **listp)
+{
+ struct module *list = *listp, *tlist = NULL, **tpos =
+ FILE *modorder;
+ int dir_len = strlen(dirname) + 1;
+ char file_name[dir_len + strlen("modules.order") + 1];
+ char line[10240];
+
+ sprintf(file_name, "%s/%s", dirname, "modules.order");
+
+ modorder = fopen(file_name, "r");
+ if (!modorder) {
+ /* Older kernels don't generate modules.order. Just
+ return if the file doesn't exist. */
+ if (errno == ENOENT)
+ return;
+ fatal("Could not open '%s': %s\n", file_name, strerror(errno));
+ }
+
+ sprintf(line, "%s/", dirname);
+
+ /* move modules listed in modorder file to tlist in order */
+ while (fgets(line, sizeof(line), modorder)) {
+ struct module **pos, *mod;
+ int len = strlen(line);
+
+ if (line[len - 1] == '\n')
+ line[len - 1] = '\0';
+
+ for (pos = (mod = *pos); pos = &(*pos)->next) {
+ if (strcmp(line, mod->pathname + dir_len) == 0) {
+ *pos = mod->next;
+ mod->next = NULL;
+ *tpos = mod;
+ tpos = >next;
+ break;
+ }
+ }
+ }
+
+ /* append the rest */
+ *tpos = list;
+
+ fclose(modorder);
+
+ *listp = tlist;
+}
+
static void parse_modules(struct module *list)
{
struct module *i;
@@ -857,6 +905,7 @@ int main(int argc, char *argv[])
} else {
list = grab_basedir(dirname);
}
+ sort_modules(dirname, );
parse_modules(list);
for (i = 0; i < sizeof(depfiles)/sizeof(depfiles[0]); i++) {
--- End Message ---
Re: [PATCH] depmod: sort output according to modules.order, take #2
Tejun Heo wrote: > Tejun Heo wrote: >> Kbuild now generates and installs modules.order along with modules. >> This patch updates depmod such that it sorts module list according to >> the file before generating output files. Modules which aren't on >> modules.order are put after modules which are ordered by >> modules.order. >> >> This makes modprobe to prioritize modules according to kernel >> Makefile's just as built-in modules are link-ordered by them. >> >> This patch is against module-init-tools 3.3-pre1. >> >> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> >> Cc: Sam Ravnborg <[EMAIL PROTECTED]> >> Cc: Bill Nottingham <[EMAIL PROTECTED]> >> Cc: Rusty Russell <[EMAIL PROTECTED]> >> Cc: Greg Kroah-Hartman <[EMAIL PROTECTED]> >> Cc: Kay Sievers <[EMAIL PROTECTED]> > > The kernel part is in now. Rusty Russell, what do you think about this > depmod change? Ping? -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order, take #2
Tejun Heo wrote: Tejun Heo wrote: Kbuild now generates and installs modules.order along with modules. This patch updates depmod such that it sorts module list according to the file before generating output files. Modules which aren't on modules.order are put after modules which are ordered by modules.order. This makes modprobe to prioritize modules according to kernel Makefile's just as built-in modules are link-ordered by them. This patch is against module-init-tools 3.3-pre1. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Sam Ravnborg [EMAIL PROTECTED] Cc: Bill Nottingham [EMAIL PROTECTED] Cc: Rusty Russell [EMAIL PROTECTED] Cc: Greg Kroah-Hartman [EMAIL PROTECTED] Cc: Kay Sievers [EMAIL PROTECTED] The kernel part is in now. Rusty Russell, what do you think about this depmod change? Ping? -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order, take #2
On Wednesday 02 January 2008 22:13:52 Tejun Heo wrote:
Tejun Heo wrote:
Tejun Heo wrote:
Kbuild now generates and installs modules.order along with modules.
This patch updates depmod such that it sorts module list according to
the file before generating output files. Modules which aren't on
modules.order are put after modules which are ordered by
modules.order.
This makes modprobe to prioritize modules according to kernel
Makefile's just as built-in modules are link-ordered by them.
The kernel part is in now. Rusty Russell, what do you think about this
depmod change?
Ping?
Oh, sorry. Jon is now module-init-tools maintainer, and I've cc'd him and
forwarded your original patch.
Thanks,
Rusty.
---BeginMessage---
Kbuild now generates and installs modules.order along with modules.
This patch updates depmod such that it sorts module list according to
the file before generating output files. Modules which aren't on
modules.order are put after modules which are ordered by
modules.order.
This makes modprobe to prioritize modules according to kernel
Makefile's just as built-in modules are link-ordered by them.
This patch is against module-init-tools 3.3-pre1.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Sam Ravnborg [EMAIL PROTECTED]
Cc: Bill Nottingham [EMAIL PROTECTED]
Cc: Rusty Russell [EMAIL PROTECTED]
Cc: Greg Kroah-Hartman [EMAIL PROTECTED]
Cc: Kay Sievers [EMAIL PROTECTED]
---
Comment added and path comparion logic slightly modified such that
dirname part of mode-pathname is ignored instead of prepending
dirname to lines read from modules.order. Behavior-wise it's
identical to the previous version.
Thanks.
depmod.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/depmod.c b/depmod.c
index ea7ad05..c3ae5a2 100644
--- a/depmod.c
+++ b/depmod.c
@@ -585,6 +585,54 @@ static struct module *grab_basedir(const char *dirname)
return list;
}
+static void sort_modules(const char *dirname, struct module **listp)
+{
+ struct module *list = *listp, *tlist = NULL, **tpos = tlist;
+ FILE *modorder;
+ int dir_len = strlen(dirname) + 1;
+ char file_name[dir_len + strlen(modules.order) + 1];
+ char line[10240];
+
+ sprintf(file_name, %s/%s, dirname, modules.order);
+
+ modorder = fopen(file_name, r);
+ if (!modorder) {
+ /* Older kernels don't generate modules.order. Just
+ return if the file doesn't exist. */
+ if (errno == ENOENT)
+ return;
+ fatal(Could not open '%s': %s\n, file_name, strerror(errno));
+ }
+
+ sprintf(line, %s/, dirname);
+
+ /* move modules listed in modorder file to tlist in order */
+ while (fgets(line, sizeof(line), modorder)) {
+ struct module **pos, *mod;
+ int len = strlen(line);
+
+ if (line[len - 1] == '\n')
+ line[len - 1] = '\0';
+
+ for (pos = list; (mod = *pos); pos = (*pos)-next) {
+ if (strcmp(line, mod-pathname + dir_len) == 0) {
+ *pos = mod-next;
+ mod-next = NULL;
+ *tpos = mod;
+ tpos = mod-next;
+ break;
+ }
+ }
+ }
+
+ /* append the rest */
+ *tpos = list;
+
+ fclose(modorder);
+
+ *listp = tlist;
+}
+
static void parse_modules(struct module *list)
{
struct module *i;
@@ -857,6 +905,7 @@ int main(int argc, char *argv[])
} else {
list = grab_basedir(dirname);
}
+ sort_modules(dirname, list);
parse_modules(list);
for (i = 0; i sizeof(depfiles)/sizeof(depfiles[0]); i++) {
---End Message---
Re: [PATCH] depmod: sort output according to modules.order, take #2
On Thu, 2008-01-03 at 10:12 +1100, Rusty Russell wrote: Oh, sorry. Jon is now module-init-tools maintainer, and I've cc'd him and forwarded your original patch. Ta. I was semi-offline last week due to holidays, but already saw the original mail and have another fix for debug sections - will sort it. Jon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order, take #2
On Fri, Dec 07, 2007 at 09:07:57PM +0900, Tejun Heo wrote: > Kbuild now generates and installs modules.order along with modules. > This patch updates depmod such that it sorts module list according to > the file before generating output files. Modules which aren't on > modules.order are put after modules which are ordered by > modules.order. > > This makes modprobe to prioritize modules according to kernel > Makefile's just as built-in modules are link-ordered by them. > > This patch is against module-init-tools 3.3-pre1. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > Cc: Sam Ravnborg <[EMAIL PROTECTED]> > Cc: Bill Nottingham <[EMAIL PROTECTED]> > Cc: Rusty Russell <[EMAIL PROTECTED]> > Cc: Greg Kroah-Hartman <[EMAIL PROTECTED]> > Cc: Kay Sievers <[EMAIL PROTECTED]> Acked-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order, take #2
On Fri, Dec 07, 2007 at 09:07:57PM +0900, Tejun Heo wrote: Kbuild now generates and installs modules.order along with modules. This patch updates depmod such that it sorts module list according to the file before generating output files. Modules which aren't on modules.order are put after modules which are ordered by modules.order. This makes modprobe to prioritize modules according to kernel Makefile's just as built-in modules are link-ordered by them. This patch is against module-init-tools 3.3-pre1. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Sam Ravnborg [EMAIL PROTECTED] Cc: Bill Nottingham [EMAIL PROTECTED] Cc: Rusty Russell [EMAIL PROTECTED] Cc: Greg Kroah-Hartman [EMAIL PROTECTED] Cc: Kay Sievers [EMAIL PROTECTED] Acked-by: Greg Kroah-Hartman [EMAIL PROTECTED] thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order, take #2
Tejun Heo wrote: > Kbuild now generates and installs modules.order along with modules. > This patch updates depmod such that it sorts module list according to > the file before generating output files. Modules which aren't on > modules.order are put after modules which are ordered by > modules.order. > > This makes modprobe to prioritize modules according to kernel > Makefile's just as built-in modules are link-ordered by them. > > This patch is against module-init-tools 3.3-pre1. > > Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> > Cc: Sam Ravnborg <[EMAIL PROTECTED]> > Cc: Bill Nottingham <[EMAIL PROTECTED]> > Cc: Rusty Russell <[EMAIL PROTECTED]> > Cc: Greg Kroah-Hartman <[EMAIL PROTECTED]> > Cc: Kay Sievers <[EMAIL PROTECTED]> The kernel part is in now. Rusty Russell, what do you think about this depmod change? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order, take #2
Tejun Heo wrote: Kbuild now generates and installs modules.order along with modules. This patch updates depmod such that it sorts module list according to the file before generating output files. Modules which aren't on modules.order are put after modules which are ordered by modules.order. This makes modprobe to prioritize modules according to kernel Makefile's just as built-in modules are link-ordered by them. This patch is against module-init-tools 3.3-pre1. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Sam Ravnborg [EMAIL PROTECTED] Cc: Bill Nottingham [EMAIL PROTECTED] Cc: Rusty Russell [EMAIL PROTECTED] Cc: Greg Kroah-Hartman [EMAIL PROTECTED] Cc: Kay Sievers [EMAIL PROTECTED] The kernel part is in now. Rusty Russell, what do you think about this depmod change? Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
Jon Masters wrote: > On Tue, 2007-12-04 at 22:55 +0900, Tejun Heo wrote: > >> Kbuild now generates and installs modules.order along with modules. >> This patch updates depmod such that it sorts module list according to >> the file before generating output files. Modules which aren't on >> modules.order are put after modules which are ordered by >> modules.order. > > Thanks. Please CC me in general on these patches :-) Sure. FYI, updated patchset is posted. http://thread.gmane.org/gmane.linux.kernel/611212 -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
> it doesn't output duplicate entries. Having duplicates is not the right > solution - especially modalias entries that depend entirely upon the > file layout on disk when you run depmod against a kernel. > > Thanks for the ordering patches folks - a good idea! And as it happens just what I need for the upcoming pata_legacy module changes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
On Sat, 2007-12-08 at 03:03 -0500, Jon Masters wrote: > On Tue, 2007-12-04 at 22:55 +0900, Tejun Heo wrote: > > > Kbuild now generates and installs modules.order along with modules. > > This patch updates depmod such that it sorts module list according to > > the file before generating output files. Modules which aren't on > > modules.order are put after modules which are ordered by > > modules.order. > > Thanks. Please CC me in general on these patches :-) > > I was planning to also discuss ordering of module aliases entries, since > we can have several modules providing the same modalias (this gets even > worse on "Enterprise Linux" distributions, where we might have third > party modules providing additional aliases). I guess this ordering is > probably better than just a numeric sort, which was the original idea. Actually, this still won't quite solve that problem, because modules not installed in the kernel itself won't have ordering data supplied. Maybe I need to do this, *and* then sort modaliases numerically aswell. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
On Thu, 2007-12-06 at 08:28 +0900, Tejun Heo 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. For what it's worth, I changed the module processing in depmod so that it doesn't output duplicate entries. Having duplicates is not the right solution - especially modalias entries that depend entirely upon the file layout on disk when you run depmod against a kernel. Thanks for the ordering patches folks - a good idea! Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
On Tue, 2007-12-04 at 22:55 +0900, Tejun Heo wrote: > Kbuild now generates and installs modules.order along with modules. > This patch updates depmod such that it sorts module list according to > the file before generating output files. Modules which aren't on > modules.order are put after modules which are ordered by > modules.order. Thanks. Please CC me in general on these patches :-) I was planning to also discuss ordering of module aliases entries, since we can have several modules providing the same modalias (this gets even worse on "Enterprise Linux" distributions, where we might have third party modules providing additional aliases). I guess this ordering is probably better than just a numeric sort, which was the original idea. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
On Sat, 2007-12-08 at 03:03 -0500, Jon Masters wrote: On Tue, 2007-12-04 at 22:55 +0900, Tejun Heo wrote: Kbuild now generates and installs modules.order along with modules. This patch updates depmod such that it sorts module list according to the file before generating output files. Modules which aren't on modules.order are put after modules which are ordered by modules.order. Thanks. Please CC me in general on these patches :-) I was planning to also discuss ordering of module aliases entries, since we can have several modules providing the same modalias (this gets even worse on Enterprise Linux distributions, where we might have third party modules providing additional aliases). I guess this ordering is probably better than just a numeric sort, which was the original idea. Actually, this still won't quite solve that problem, because modules not installed in the kernel itself won't have ordering data supplied. Maybe I need to do this, *and* then sort modaliases numerically aswell. Jon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
On Thu, 2007-12-06 at 08:28 +0900, Tejun Heo 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. For what it's worth, I changed the module processing in depmod so that it doesn't output duplicate entries. Having duplicates is not the right solution - especially modalias entries that depend entirely upon the file layout on disk when you run depmod against a kernel. Thanks for the ordering patches folks - a good idea! Jon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
On Tue, 2007-12-04 at 22:55 +0900, Tejun Heo wrote: Kbuild now generates and installs modules.order along with modules. This patch updates depmod such that it sorts module list according to the file before generating output files. Modules which aren't on modules.order are put after modules which are ordered by modules.order. Thanks. Please CC me in general on these patches :-) I was planning to also discuss ordering of module aliases entries, since we can have several modules providing the same modalias (this gets even worse on Enterprise Linux distributions, where we might have third party modules providing additional aliases). I guess this ordering is probably better than just a numeric sort, which was the original idea. Jon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
it doesn't output duplicate entries. Having duplicates is not the right solution - especially modalias entries that depend entirely upon the file layout on disk when you run depmod against a kernel. Thanks for the ordering patches folks - a good idea! And as it happens just what I need for the upcoming pata_legacy module changes -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
Jon Masters wrote: On Tue, 2007-12-04 at 22:55 +0900, Tejun Heo wrote: Kbuild now generates and installs modules.order along with modules. This patch updates depmod such that it sorts module list according to the file before generating output files. Modules which aren't on modules.order are put after modules which are ordered by modules.order. Thanks. Please CC me in general on these patches :-) Sure. FYI, updated patchset is posted. http://thread.gmane.org/gmane.linux.kernel/611212 -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
On Thu, Dec 06, 2007 at 08:28:03AM +0900, Tejun Heo wrote: > 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. googled a bit. It looks like: awk '!x[$0]++' does the trick. So we can skip the C file (good thing). > > > 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 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 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. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
On Thu, Dec 06, 2007 at 08:28:03AM +0900, Tejun Heo wrote: 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. googled a bit. It looks like: awk '!x[$0]++' does the trick. So we can skip the C file (good thing). 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 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 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. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
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. And this change in Makefile.lib seems bogus: +# make sure '/' follows subdirs +subdir-y := $(patsubst %//,%/, $(addsuffix, /,$subdir-y)) +subdir-m := $(patsubst %//,%/, $(addsuffix, /,$subdir-m)) I commented it out and with my config everything seems to still work as expected. And I get scripts/mod/modpost built in a mrproper tree again (bug!). 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 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). And I did not try out depmod at all. Feel free to use this as an updated patch. Sam diff --git a/Makefile b/Makefile index 92dc3cb..9309e89 100644 --- a/Makefile +++ b/Makefile @@ -1023,6 +1023,7 @@ all: modules PHONY += modules modules: $(vmlinux-dirs) $(if $(KBUILD_BUILTIN),vmlinux) + $(Q)cat $(vmlinux-dirs:%=$(objtree)/%/modules.order) > $(objtree)/modules.order @echo ' Building modules, stage 2.'; $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost @@ -1050,6 +1051,7 @@ _modinst_: rm -f $(MODLIB)/build ; \ ln -s $(objtree) $(MODLIB)/build ; \ fi + @cp -f $(objtree)/modules.order $(MODLIB)/ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst # This depmod is only for convenience to give the initial @@ -1109,7 +,7 @@ clean: archclean $(clean-dirs) @find . $(RCS_FIND_IGNORE) \ \( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \ -o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \ - -o -name '*.symtypes' \) \ + -o -name '*.symtypes' -o -name 'modules.order' \) \ -type f -print | xargs rm -f # mrproper - Delete all generated files, including .config diff --git a/scripts/Makefile.build b/scripts/Makefile.build index de9836e..ac68c70 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -83,10 +83,12 @@ ifneq ($(strip $(obj-y) $(obj-m) $(obj-n) $(obj-) $(lib-target)),) builtin-target := $(obj)/built-in.o endif +modorder-target := $(obj)/modules.order + # We keep a list of all modules in $(MODVERDIR) __build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y)) \ -$(if $(KBUILD_MODULES),$(obj-m)) \ +$(if $(KBUILD_MODULES),$(obj-m) $(modorder-target)) \ $(subdir-ym) $(always) @: @@ -276,6 +278,18 @@ targets += $(builtin-target) endif # builtin-target # +# Rule to create modules.order file +# +# Create commands to etiher record .ko file +# or cat modules.order from a subdirectory +modorder-cmds =\ + $(foreach m, $(modorder), \ + $(if $(filter %/modules.order, $m),\ + cat $m;, echo kernel/$m;)) + +$(modorder-target): $(subdir-ym) FORCE + $(Q)(cat /dev/null; $(modorder-cmds)) > $@ +# # Rule to compile a set of .o files into one .a file # ifdef lib-target diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 3c5e88b..4dedea1 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -25,6 +25,11 @@ lib-y := $(filter-out $(obj-y), $(sort $(lib-y) $(lib-m))) # o if we encounter foo/ in $(obj-m), remove it from $(obj-m) # and add the directory to the list of dirs to descend into: $(subdir-m) +# Determine modorder. +# Unfortunately we don't have information about ordering between -y +# and -m subdirs. Just put -y's first. +modorder := $(patsubst %/,%/modules.order, $(filter %/, $(obj-y)) $(obj-m:.o=.ko)) + __subdir-y := $(patsubst %/,%,$(filter %/, $(obj-y))) subdir-y += $(__subdir-y) __subdir-m := $(patsubst %/,%,$(filter %/, $(obj-m))) @@ -64,6 +69,7 @@ real-objs-m := $(foreach m, $(obj-m), $(if $(strip $($(m:.o=-objs)) $($(m:.o=-y) extra-y:= $(addprefix $(obj)/,$(extra-y)) always := $(addprefix $(obj)/,$(always)) targets:= $(addprefix $(obj)/,$(targets)) +modorder := $(addprefix $(obj)/,$(modorder)) obj-y := $(addprefix $(obj)/,$(obj-y)) obj-m := $(addprefix
Re: [PATCH] depmod: sort output according to modules.order
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. And this change in Makefile.lib seems bogus: +# make sure '/' follows subdirs +subdir-y := $(patsubst %//,%/, $(addsuffix, /,$subdir-y)) +subdir-m := $(patsubst %//,%/, $(addsuffix, /,$subdir-m)) I commented it out and with my config everything seems to still work as expected. And I get scripts/mod/modpost built in a mrproper tree again (bug!). 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 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). And I did not try out depmod at all. Feel free to use this as an updated patch. Sam diff --git a/Makefile b/Makefile index 92dc3cb..9309e89 100644 --- a/Makefile +++ b/Makefile @@ -1023,6 +1023,7 @@ all: modules PHONY += modules modules: $(vmlinux-dirs) $(if $(KBUILD_BUILTIN),vmlinux) + $(Q)cat $(vmlinux-dirs:%=$(objtree)/%/modules.order) $(objtree)/modules.order @echo ' Building modules, stage 2.'; $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost @@ -1050,6 +1051,7 @@ _modinst_: rm -f $(MODLIB)/build ; \ ln -s $(objtree) $(MODLIB)/build ; \ fi + @cp -f $(objtree)/modules.order $(MODLIB)/ $(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst # This depmod is only for convenience to give the initial @@ -1109,7 +,7 @@ clean: archclean $(clean-dirs) @find . $(RCS_FIND_IGNORE) \ \( -name '*.[oas]' -o -name '*.ko' -o -name '.*.cmd' \ -o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \ - -o -name '*.symtypes' \) \ + -o -name '*.symtypes' -o -name 'modules.order' \) \ -type f -print | xargs rm -f # mrproper - Delete all generated files, including .config diff --git a/scripts/Makefile.build b/scripts/Makefile.build index de9836e..ac68c70 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -83,10 +83,12 @@ ifneq ($(strip $(obj-y) $(obj-m) $(obj-n) $(obj-) $(lib-target)),) builtin-target := $(obj)/built-in.o endif +modorder-target := $(obj)/modules.order + # We keep a list of all modules in $(MODVERDIR) __build: $(if $(KBUILD_BUILTIN),$(builtin-target) $(lib-target) $(extra-y)) \ -$(if $(KBUILD_MODULES),$(obj-m)) \ +$(if $(KBUILD_MODULES),$(obj-m) $(modorder-target)) \ $(subdir-ym) $(always) @: @@ -276,6 +278,18 @@ targets += $(builtin-target) endif # builtin-target # +# Rule to create modules.order file +# +# Create commands to etiher record .ko file +# or cat modules.order from a subdirectory +modorder-cmds =\ + $(foreach m, $(modorder), \ + $(if $(filter %/modules.order, $m),\ + cat $m;, echo kernel/$m;)) + +$(modorder-target): $(subdir-ym) FORCE + $(Q)(cat /dev/null; $(modorder-cmds)) $@ +# # Rule to compile a set of .o files into one .a file # ifdef lib-target diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib index 3c5e88b..4dedea1 100644 --- a/scripts/Makefile.lib +++ b/scripts/Makefile.lib @@ -25,6 +25,11 @@ lib-y := $(filter-out $(obj-y), $(sort $(lib-y) $(lib-m))) # o if we encounter foo/ in $(obj-m), remove it from $(obj-m) # and add the directory to the list of dirs to descend into: $(subdir-m) +# Determine modorder. +# Unfortunately we don't have information about ordering between -y +# and -m subdirs. Just put -y's first. +modorder := $(patsubst %/,%/modules.order, $(filter %/, $(obj-y)) $(obj-m:.o=.ko)) + __subdir-y := $(patsubst %/,%,$(filter %/, $(obj-y))) subdir-y += $(__subdir-y) __subdir-m := $(patsubst %/,%,$(filter %/, $(obj-m))) @@ -64,6 +69,7 @@ real-objs-m := $(foreach m, $(obj-m), $(if $(strip $($(m:.o=-objs)) $($(m:.o=-y) extra-y:= $(addprefix $(obj)/,$(extra-y)) always := $(addprefix $(obj)/,$(always)) targets:= $(addprefix $(obj)/,$(targets)) +modorder := $(addprefix $(obj)/,$(modorder)) obj-y := $(addprefix $(obj)/,$(obj-y)) obj-m := $(addprefix $(obj)/,$(obj-m)) lib-y
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
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. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
Sam Ravnborg wrote: > Hi Tejun. > On Tue, Dec 04, 2007 at 10:55:48PM +0900, Tejun Heo wrote: >> Kbuild now generates and installs modules.order along with modules. >> This patch updates depmod such that it sorts module list according to >> the file before generating output files. Modules which aren't on >> modules.order are put after modules which are ordered by >> modules.order. >> >> This makes modprobe to prioritize modules according to kernel >> Makefile's just as built-in modules are link-ordered by them. > > With this change depmod require the precense of modules.order. > Could we make it optional so depmod are backward compatible? It is backward compatible by virtue of + if (errno == ENOENT) + return; in sort_modules(). If the file isn't there, the list isn't sorted. > 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. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
Hi Tejun. On Tue, Dec 04, 2007 at 10:55:48PM +0900, Tejun Heo wrote: > Kbuild now generates and installs modules.order along with modules. > This patch updates depmod such that it sorts module list according to > the file before generating output files. Modules which aren't on > modules.order are put after modules which are ordered by > modules.order. > > This makes modprobe to prioritize modules according to kernel > Makefile's just as built-in modules are link-ordered by them. With this change depmod require the precense of modules.order. Could we make it optional so depmod are backward compatible? 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. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
Hi Tejun. On Tue, Dec 04, 2007 at 10:55:48PM +0900, Tejun Heo wrote: Kbuild now generates and installs modules.order along with modules. This patch updates depmod such that it sorts module list according to the file before generating output files. Modules which aren't on modules.order are put after modules which are ordered by modules.order. This makes modprobe to prioritize modules according to kernel Makefile's just as built-in modules are link-ordered by them. With this change depmod require the precense of modules.order. Could we make it optional so depmod are backward compatible? 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. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
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. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] depmod: sort output according to modules.order
Sam Ravnborg wrote: Hi Tejun. On Tue, Dec 04, 2007 at 10:55:48PM +0900, Tejun Heo wrote: Kbuild now generates and installs modules.order along with modules. This patch updates depmod such that it sorts module list according to the file before generating output files. Modules which aren't on modules.order are put after modules which are ordered by modules.order. This makes modprobe to prioritize modules according to kernel Makefile's just as built-in modules are link-ordered by them. With this change depmod require the precense of modules.order. Could we make it optional so depmod are backward compatible? It is backward compatible by virtue of + if (errno == ENOENT) + return; in sort_modules(). If the file isn't there, the list isn't sorted. 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. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
