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
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 modules
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
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 modules
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
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
> >>
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
listed in
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.order
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
>>
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
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
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
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
modules.
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 are
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
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 iterating free logic?
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
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
>> 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.
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
{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
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
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
{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 stdio.h
+#include
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 from web.
+
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.
--
To
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 hate bugs.
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 leaks are bugs. And
28 matches
Mail list logo
