Re: [PATCH] kbuild: implement modules.order, take #2

2007-12-12 Thread Greg KH
On Fri, Dec 07, 2007 at 09:04:30PM +0900, Tejun Heo wrote: > When multiple built-in modules (especially drivers) provide the same > capability, they're prioritized by link order specified by the order > listed in Makefile. This implicit ordering is lost for loadable > modules. > > When driver mod

Re: [PATCH] kbuild: implement modules.order, take #2

2007-12-09 Thread Sam Ravnborg
On Fri, Dec 07, 2007 at 09:04:30PM +0900, Tejun Heo wrote: > When multiple built-in modules (especially drivers) provide the same > capability, they're prioritized by link order specified by the order > listed in Makefile. This implicit ordering is lost for loadable > modules. > > When driver mod

Re: [PATCH] kbuild: implement modules.order

2007-12-08 Thread Tejun Heo
Adrian Bunk wrote: > And thinking about it, it doesn't seem to add any problems regarding > what I have in mind: > > If we would ever stop having any well-defined link-order for in-kernel > code and express everything through initcall levels, we simply must > additionally update the modules.ord

Re: [PATCH] kbuild: implement modules.order

2007-12-08 Thread Adrian Bunk
On Sat, Dec 08, 2007 at 08:59:31AM +0900, Tejun Heo wrote: > Adrian Bunk wrote: > > On Tue, Dec 04, 2007 at 10:49:37PM +0900, Tejun Heo wrote: > >> When multiple built-in modules (especially drivers) provide the same > >> capability, they're prioritized by link order specified by the order > >> lis

Re: [PATCH] kbuild: implement modules.order

2007-12-07 Thread Tejun Heo
Adrian Bunk wrote: > On Tue, Dec 04, 2007 at 10:49:37PM +0900, Tejun Heo wrote: >> When multiple built-in modules (especially drivers) provide the same >> capability, they're prioritized by link order specified by the order >> listed in Makefile. This implicit ordering is lost for loadable >> modu

Re: [PATCH] kbuild: implement modules.order

2007-12-07 Thread Adrian Bunk
On Tue, Dec 04, 2007 at 10:49:37PM +0900, Tejun Heo wrote: > When multiple built-in modules (especially drivers) provide the same > capability, they're prioritized by link order specified by the order > listed in Makefile. This implicit ordering is lost for loadable > modules. >... What exactly a

[PATCH] kbuild: implement modules.order, take #2

2007-12-07 Thread Tejun Heo
When multiple built-in modules (especially drivers) provide the same capability, they're prioritized by link order specified by the order listed in Makefile. This implicit ordering is lost for loadable modules. When driver modules are loaded by udev, what comes first in modules.alias file is sele

Re: [PATCH] kbuild: implement modules.order

2007-12-05 Thread Rusty Russell
On Wednesday 05 December 2007 18:11:49 Tejun Heo wrote: > WANG Cong wrote: > >>> I think, you forgot to free(3) the memory you calloc(3)'ed and > >>> malloc(3)'ed above. > >> > >> It's a simple program where whole body is in main(). Why bother? > >> What's the benefit of adding hash-table iteratin

Re: [PATCH] kbuild: implement modules.order

2007-12-04 Thread Li Zefan
Tejun Heo wrote: > WANG Cong wrote: I think, you forgot to free(3) the memory you calloc(3)'ed and malloc(3)'ed above. >>> It's a simple program where whole body is in main(). Why bother? >>> What's the benefit of adding hash-table iterating free logic? >>> >> Personally, I think memory

Re: [PATCH] kbuild: implement modules.order

2007-12-04 Thread Tejun Heo
WANG Cong wrote: >>> I think, you forgot to free(3) the memory you calloc(3)'ed and >>> malloc(3)'ed above. >> It's a simple program where whole body is in main(). Why bother? >> What's the benefit of adding hash-table iterating free logic? >> > > Personally, I think memory leaks are bugs. And we

Re: [PATCH] kbuild: implement modules.order

2007-12-04 Thread WANG Cong
>> I think, you forgot to free(3) the memory you calloc(3)'ed and >> malloc(3)'ed above. > >It's a simple program where whole body is in main(). Why bother? >What's the benefit of adding hash-table iterating free logic? > Personally, I think memory leaks are bugs. And we hate bugs. ;) Regards.

Re: [PATCH] kbuild: implement modules.order

2007-12-04 Thread Tejun Heo
WANG Cong wrote: >> +static inline unsigned int sdb_hash(const char *str) >> +{ >> +unsigned int hash = 0; >> +int c; >> + >> +while ((c = *str++)) > > Maybe ` while ((c = *str++) != '\0') ` is better. ;) Yeah, probably. That hash function is copied & pasted mindlessly fr

Re: [PATCH] kbuild: implement modules.order

2007-12-04 Thread WANG Cong
{snip} Comments on your C code below. >--- /dev/null >+++ b/scripts/remove-dup.c >@@ -0,0 +1,98 @@ >+/* >+ * remove-dup - Drop duplicate lines from unsorted input files >+ * >+ * Dec 2007 Tejun Heo <[EMAIL PROTECTED]> >+ * >+ * This software is released under GPLv2. >+ */ >+ >+#include >+#inclu

[PATCH] kbuild: implement modules.order

2007-12-04 Thread Tejun Heo
When multiple built-in modules (especially drivers) provide the same capability, they're prioritized by link order specified by the order listed in Makefile. This implicit ordering is lost for loadable modules. When driver modules are loaded by udev, what comes first in modules.alias file is sele