> If this was code that affected all systems, the impact would be greater
> - and it would be much easier to test.
I can follow such a view to some degree.
Would you dare to test the deletion of questionable error messages
more with any other software components?
> As it applies only to
> If this was code that affected all systems, the impact would be greater
> - and it would be much easier to test.
I can follow such a view to some degree.
Would you dare to test the deletion of questionable error messages
more with any other software components?
> As it applies only to
On Wed, Jan 03, 2018 at 09:41:04AM +0100, SF Markus Elfring wrote:
> > I understand it can be frustrating to encounter different policies
> > across kernel maintainers.
>
> The change acceptance is varying for special transformation patterns.
>
>
> > You'll even run in to this with maintainers
On Wed, Jan 03, 2018 at 09:41:04AM +0100, SF Markus Elfring wrote:
> > I understand it can be frustrating to encounter different policies
> > across kernel maintainers.
>
> The change acceptance is varying for special transformation patterns.
>
>
> > You'll even run in to this with maintainers
> I understand it can be frustrating to encounter different policies
> across kernel maintainers.
The change acceptance is varying for special transformation patterns.
> You'll even run in to this with maintainers of the same subsystem
> from time to time.
Interesting, isn't it?
> I'm
> I understand it can be frustrating to encounter different policies
> across kernel maintainers.
The change acceptance is varying for special transformation patterns.
> You'll even run in to this with maintainers of the same subsystem
> from time to time.
Interesting, isn't it?
> I'm
On Tue, Jan 02, 2018 at 04:49:43PM -0800, Joe Perches wrote:
> On Tue, 2018-01-02 at 16:10 -0800, Darren Hart wrote:
> > > > Leave those pr_ messages alone, please,
> []
> > Andy and Henrique raised a few reasons why these patches should not be
> > accepted:
> >
> > 1. This is init code (so any
On Tue, Jan 02, 2018 at 04:49:43PM -0800, Joe Perches wrote:
> On Tue, 2018-01-02 at 16:10 -0800, Darren Hart wrote:
> > > > Leave those pr_ messages alone, please,
> []
> > Andy and Henrique raised a few reasons why these patches should not be
> > accepted:
> >
> > 1. This is init code (so any
On Tue, 2018-01-02 at 16:10 -0800, Darren Hart wrote:
> > > Leave those pr_ messages alone, please,
[]
> Andy and Henrique raised a few reasons why these patches should not be
> accepted:
>
> 1. This is init code (so any space savings is short lived)
Not exactly true.
The object code itself is
On Tue, 2018-01-02 at 16:10 -0800, Darren Hart wrote:
> > > Leave those pr_ messages alone, please,
[]
> Andy and Henrique raised a few reasons why these patches should not be
> accepted:
>
> 1. This is init code (so any space savings is short lived)
Not exactly true.
The object code itself is
On Sat, Dec 23, 2017 at 08:12:21AM +0100, SF Markus Elfring wrote:
> >> Do you find the Linux allocation failure report insufficient in this case?
> >
> > Leave those pr_ messages alone, please,
>
> Have you got special software development concerns?
>
>
> > unless they are really causing some
On Sat, Dec 23, 2017 at 08:12:21AM +0100, SF Markus Elfring wrote:
> >> Do you find the Linux allocation failure report insufficient in this case?
> >
> > Leave those pr_ messages alone, please,
>
> Have you got special software development concerns?
>
>
> > unless they are really causing some
>> Do you find the Linux allocation failure report insufficient in this case?
>
> Leave those pr_ messages alone, please,
Have you got special software development concerns?
> unless they are really causing some sort of issue (which?).
Can the code be redundant here?
> Doing it just for
>> Do you find the Linux allocation failure report insufficient in this case?
>
> Leave those pr_ messages alone, please,
Have you got special software development concerns?
> unless they are really causing some sort of issue (which?).
Can the code be redundant here?
> Doing it just for
On Tue, 19 Dec 2017, SF Markus Elfring wrote:
> >> Delete an error message for a failed memory allocation in three functions
> >
> > This one is questionable since it prints error messages at ->init() stage.
> > I would rather not touch this.
>
> Do you find the Linux allocation failure report
On Tue, 19 Dec 2017, SF Markus Elfring wrote:
> >> Delete an error message for a failed memory allocation in three functions
> >
> > This one is questionable since it prints error messages at ->init() stage.
> > I would rather not touch this.
>
> Do you find the Linux allocation failure report
On Tue, 19 Dec 2017, Andy Shevchenko wrote:
> On Mon, Dec 18, 2017 at 11:26 PM, SF Markus Elfring
> wrote:
> > From: Markus Elfring
> > Date: Mon, 18 Dec 2017 22:23:45 +0100
> >
> > Two update suggestions were taken into account
> >
On Tue, 19 Dec 2017, Andy Shevchenko wrote:
> On Mon, Dec 18, 2017 at 11:26 PM, SF Markus Elfring
> wrote:
> > From: Markus Elfring
> > Date: Mon, 18 Dec 2017 22:23:45 +0100
> >
> > Two update suggestions were taken into account
> > from static source code analysis.
> >
> > Markus Elfring (2):
>
On Tue, Dec 19, 2017 at 6:23 PM, SF Markus Elfring
wrote:
>>> Delete an error message for a failed memory allocation in three functions
>>
>> This one is questionable since it prints error messages at ->init() stage.
>> I would rather not touch this.
>
> Do you
On Tue, Dec 19, 2017 at 6:23 PM, SF Markus Elfring
wrote:
>>> Delete an error message for a failed memory allocation in three functions
>>
>> This one is questionable since it prints error messages at ->init() stage.
>> I would rather not touch this.
>
> Do you find the Linux allocation failure
>> Delete an error message for a failed memory allocation in three functions
>
> This one is questionable since it prints error messages at ->init() stage.
> I would rather not touch this.
Do you find the Linux allocation failure report insufficient in this case?
>> Improve a size
>> Delete an error message for a failed memory allocation in three functions
>
> This one is questionable since it prints error messages at ->init() stage.
> I would rather not touch this.
Do you find the Linux allocation failure report insufficient in this case?
>> Improve a size
On Mon, Dec 18, 2017 at 11:26 PM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Mon, 18 Dec 2017 22:23:45 +0100
>
> Two update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (2):
>
On Mon, Dec 18, 2017 at 11:26 PM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Mon, 18 Dec 2017 22:23:45 +0100
>
> Two update suggestions were taken into account
> from static source code analysis.
>
> Markus Elfring (2):
> Delete an error message for a failed memory allocation in
From: Markus Elfring
Date: Mon, 18 Dec 2017 22:23:45 +0100
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation in three functions
Improve a size
From: Markus Elfring
Date: Mon, 18 Dec 2017 22:23:45 +0100
Two update suggestions were taken into account
from static source code analysis.
Markus Elfring (2):
Delete an error message for a failed memory allocation in three functions
Improve a size determination in tpacpi_new_rfkill()
26 matches
Mail list logo