On Tue, Feb 26, 2019 at 6:58 AM Cong Wang wrote:
>
> On Mon, Feb 25, 2019 at 2:29 PM David Miller wrote:
> >
> > From: Cong Wang
> > Date: Mon, 25 Feb 2019 14:00:09 -0800
> >
> > > Just to clarify, I have been suggesting to completely remove
> > > this unused macro, never suggest to just undefin
(Cc'ing LKML)
On Mon, Feb 25, 2019 at 3:11 PM David Miller wrote:
>
> From: Cong Wang
> Date: Mon, 25 Feb 2019 14:58:36 -0800
>
> > Please be specific, and ideally make it a formal doc in netdev-FAQ.txt.
>
> And this isn't happening either Cong, I reserve the right to apply my
> judgment as netw
From: Cong Wang
Date: Mon, 25 Feb 2019 14:58:36 -0800
> Please be specific, and ideally make it a formal doc in netdev-FAQ.txt.
And this isn't happening either Cong, I reserve the right to apply my
judgment as networking maintainer on a case by case basis as I so see
fit.
From: Cong Wang
Date: Mon, 25 Feb 2019 14:58:36 -0800
> So you agree that I can add debugging printk's only for my own use?
Let's put it this way.
If I ignore the fact that some of the data centers with the furtest
reach on the entire planet use something that is in the tree already,
then I am
On Mon, Feb 25, 2019 at 2:29 PM David Miller wrote:
>
> From: Cong Wang
> Date: Mon, 25 Feb 2019 14:00:09 -0800
>
> > Just to clarify, I have been suggesting to completely remove
> > this unused macro, never suggest to just undefine it in-tree.
> >
> > There is no reason to keep it in-tree, wheth
From: Cong Wang
Date: Mon, 25 Feb 2019 14:00:09 -0800
> Just to clarify, I have been suggesting to completely remove
> this unused macro, never suggest to just undefine it in-tree.
>
> There is no reason to keep it in-tree, whether defined or undefined,
> just for downstream users.
And this is
On Sat, Feb 23, 2019 at 6:31 PM David Miller wrote:
>
> From: Cong Wang
> Date: Sat, 23 Feb 2019 17:11:08 -0800
>
> > On Sat, Feb 23, 2019 at 1:21 PM David Miller wrote:
> >>
> >> You are forcing everyone who wants to use this to add a curstom local
> >> source code change into their build.
> >
From: Cong Wang
Date: Sat, 23 Feb 2019 17:11:08 -0800
> On Sat, Feb 23, 2019 at 1:21 PM David Miller wrote:
>>
>> You are forcing everyone who wants to use this to add a curstom local
>> source code change into their build.
>
> What's wrong with this? People carry custom changes in anyway,
> do
On Sat, Feb 23, 2019 at 1:21 PM David Miller wrote:
>
> From: Yafang Shao
> Date: Sun, 17 Feb 2019 22:26:32 +0800
> > The reason why I don't remove it comepletely is that someone may still
> > would like to use it for debugging.
Please remove it completely.
The rule here is we upstream only car
On Sat, Feb 23, 2019 at 1:21 PM David Miller wrote:
>
> You are forcing everyone who wants to use this to add a curstom local
> source code change into their build.
What's wrong with this? People carry custom changes in anyway,
do we really need to care about all the downstream changes?
If yes,
On Sat, 2019-02-23 at 13:21 -0800, David Miller wrote:
> From: Yafang Shao
> Date: Sun, 17 Feb 2019 22:26:32 +0800
>
> > SOCK_DEBUG() is a old facility for debugging.
> > If the user want to use it for debugging, the user must modify the
> > application first, that doesn't seem like a good way.
>
From: Yafang Shao
Date: Sun, 17 Feb 2019 22:26:32 +0800
> SOCK_DEBUG() is a old facility for debugging.
> If the user want to use it for debugging, the user must modify the
> application first, that doesn't seem like a good way.
> Now we have more powerful facilities, i.e. bpf or tracepoint, for
SOCK_DEBUG() is a old facility for debugging.
If the user want to use it for debugging, the user must modify the
application first, that doesn't seem like a good way.
Now we have more powerful facilities, i.e. bpf or tracepoint, for this kind
of debugging purpose.
So we'd better disable it by defau
13 matches
Mail list logo
