"Jan Beulich" <[EMAIL PROTECTED]> wrote:
>
> First, I rarely saw any kind of positive review feedback from lkml
> besides the notification that you added something to your -mm tree
> (negative things of course always arrive), yet no feedback at all is far
> from meaning that a given patch is eve
Jan wrote:
> Hence I wouldn't consider it reasonable to
> break up the debugger patch entirely and submit all the pieces at once,
> because that could easily mean that if one intermediate piece doesn't
> get accepted all the dependent pieces have been separated out
> pointlessly.
This statement so
On 9/9/05, Jan Beulich <[EMAIL PROTECTED]> wrote:
[snip]
>
> First, I rarely saw any kind of positive review feedback from lkml
> besides the notification that you added something to your -mm tree
> (negative things of course always arrive), yet no feedback at all is far
[snip]
I wouldn't say onl
>> That's funny - on one hand I'm asked to not submit huge patches (not
by
>> you, but by others), but on the other hand not having the consuming
code
>> in the same patch as the providing one is now deemed to be a
problem.
>
>Nope.
>
>Each patch should do a single logical thing. That doesn't mean
>>> Tom Rini <[EMAIL PROTECTED]> 08.09.05 17:33:14 >>>
>On Thu, Sep 08, 2005 at 05:03:58PM +0200, Jan Beulich wrote:
>It's possible to do this a bit differently, if I'm guessing right at
>what NLKD does. The following is from the KGDB patches (trimmed of
some
>other, unrelated to the notify part c
"Jan Beulich" <[EMAIL PROTECTED]> wrote:
>
> >>> Christoph Hellwig <[EMAIL PROTECTED]> 08.09.05 17:16:24 >>>
> >On Thu, Sep 08, 2005 at 05:03:58PM +0200, Jan Beulich wrote:
> >> (Note: Patch also attached because the inline version is certain to
> get
> >> line wrapped.)
Suggest you get a new emai
>It's possible to do this a bit differently, if I'm guessing right at
>what NLKD does. The following is from the KGDB patches (trimmed of
some
>other, unrelated to the notify part code):
Hmm, yes, this seems to be the better way to go.
Thanks, Jan
-
To unsubscribe from this list: send the line "
On Thu, Sep 08, 2005 at 05:03:58PM +0200, Jan Beulich wrote:
> (Note: Patch also attached because the inline version is certain to get
> line wrapped.)
>
> Debugging and maintenance support code occasionally needs to know not
> only of module insertions, but also modulke removals. This adds a
> n
>> Debugging and maintenance support code occasionally needs to know
not
>> only of module insertions, but also modulke removals. This adds a
>> notifier
>> chain for this purpose.
>>
>>
>> diff -Npru 2.6.13/kernel/module.c
>> 2.6.13-rmmod-notifier/kernel/module.c
>> --- 2.6.13/kernel/module.c 2
On Thu, Sep 08, 2005 at 05:03:58PM +0200, Jan Beulich wrote:
> (Note: Patch also attached because the inline version is certain to get
> line wrapped.)
>
> Debugging and maintenance support code occasionally needs to know not
> only of module insertions, but also modulke removals. This adds a
> no
On Thu, Sep 08, 2005 at 04:16:24PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 08, 2005 at 05:03:58PM +0200, Jan Beulich wrote:
> > (Note: Patch also attached because the inline version is certain to get
> > line wrapped.)
> >
> > Debugging and maintenance support code occasionally needs to know
>>> Christoph Hellwig <[EMAIL PROTECTED]> 08.09.05 17:16:24 >>>
>On Thu, Sep 08, 2005 at 05:03:58PM +0200, Jan Beulich wrote:
>> (Note: Patch also attached because the inline version is certain to
get
>> line wrapped.)
>>
>> Debugging and maintenance support code occasionally needs to know
not
>>
Jan Beulich wrote:
> Debugging and maintenance support code occasionally needs to know not
> only of module insertions, but also modulke removals. This adds a
> notifier
> chain for this purpose.
>
>
> diff -Npru 2.6.13/kernel/module.c
> 2.6.13-rmmod-notifier/kernel/module.c
> --- 2.6.13/kernel/mo
13 matches
Mail list logo
