From: Mahesh Bandewar <redacted>
In almost every scenario the loopback device is brought UP after
initialization. So there is no point of bringing up the device in
DOWN state followed by device UP operation. This change exposed
another issue of fib-trie initialization which is corrected in the
first path.
Mahesh Bandewar (2):
ipv4: initialize fib_trie prior to register_netdev_notifier call.
loopback: bringup 'lo' by default at initialization
drivers/net/loopback.c | 6 ++++++
net/ipv4/fib_frontend.c | 4 ++--
2 files changed, 8 insertions(+), 2 deletions(-)
--
2.13.2.725.g09c95d1e9-goog
In almost every scenario the loopback device is brought UP after
initialization. So there is no point of bringing up the device in
DOWN state followed by device UP operation. This change exposed
another issue of fib-trie initialization which is corrected in the
first path.
You use the word almost, which supports my position that someone may
not want this.
I also don't see it as so much of a burdon to bring the lo device up
explicitly. Systems have been having to do that since the beginning
of time.
Sorry I'm not applying this.
In almost every scenario the loopback device is brought UP after
initialization. So there is no point of bringing up the device in
DOWN state followed by device UP operation. This change exposed
another issue of fib-trie initialization which is corrected in the
first path.
You use the word almost, which supports my position that someone may
not want this.
I also don't see it as so much of a burdon to bring the lo device up
explicitly. Systems have been having to do that since the beginning
of time.
Systems have only one lo device (since ages) and that is usually taken
care at the boot time. Now with the namespaces it's not just one
device as it's per namespace and though not much this patch will
benefit a little. Probably we should ask a question - is it going to
have any bad effects? I couldn't find any and my RFC patch did not get
me any such feedback. As far as the good effects are concerned, it has
already found a bug (another patch in this series)! Also sometime back
I did experience weird behavior inside net-namespace if you forget to
bring-up the loopback device. I didn't pay too much attention as
bringing up the lo device fixed it.
In almost every scenario the loopback device is brought UP after
initialization. So there is no point of bringing up the device in
DOWN state followed by device UP operation. This change exposed
another issue of fib-trie initialization which is corrected in the
first path.
You use the word almost, which supports my position that someone may
not want this.
I also don't see it as so much of a burdon to bring the lo device up
explicitly. Systems have been having to do that since the beginning
of time.
Systems have only one lo device (since ages) and that is usually taken
care at the boot time. Now with the namespaces it's not just one
device as it's per namespace and though not much this patch will
benefit a little. Probably we should ask a question - is it going to
have any bad effects? I couldn't find any and my RFC patch did not get
me any such feedback. As far as the good effects are concerned, it has
already found a bug (another patch in this series)! Also sometime back
I did experience weird behavior inside net-namespace if you forget to
bring-up the loopback device. I didn't pay too much attention as
bringing up the lo device fixed it.
You're not talking at all about why specifically you need this
(ie. your use case) when you are spinning up namespaces for users.
I do happen to know those details, but you need to talk about this
explicitly in your commit log messages and in this discussion so that
everyone else understands this as well.
Thank you.
From: Cong Wang <hidden> Date: 2017-07-05 17:49:23
On Wed, Jul 5, 2017 at 8:59 AM, Mahesh Bandewar (महेश बंडेवार)
[off-list ref] wrote:
Systems have only one lo device (since ages) and that is usually taken
care at the boot time. Now with the namespaces it's not just one
device as it's per namespace and though not much this patch will
benefit a little. Probably we should ask a question - is it going to
have any bad effects? I couldn't find any and my RFC patch did not get
me any such feedback. As far as the good effects are concerned, it has
already found a bug (another patch in this series)! Also sometime back
I did experience weird behavior inside net-namespace if you forget to
bring-up the loopback device. I didn't pay too much attention as
bringing up the lo device fixed it.
I wonder if it is too late to change this since this behavior is probably
from the beginning of network namespace. A networkless netns is also
useful at least for testing purpose, we do use it as a sandbox.
In almost every scenario the loopback device is brought UP after
initialization. So there is no point of bringing up the device in
DOWN state followed by device UP operation. This change exposed
another issue of fib-trie initialization which is corrected in the
first path.
You use the word almost, which supports my position that someone may
not want this.
I also don't see it as so much of a burdon to bring the lo device up
explicitly. Systems have been having to do that since the beginning
of time.
Systems have only one lo device (since ages) and that is usually taken
care at the boot time. Now with the namespaces it's not just one
device as it's per namespace and though not much this patch will
benefit a little. Probably we should ask a question - is it going to
have any bad effects? I couldn't find any and my RFC patch did not get
me any such feedback. As far as the good effects are concerned, it has
already found a bug (another patch in this series)! Also sometime back
I did experience weird behavior inside net-namespace if you forget to
bring-up the loopback device. I didn't pay too much attention as
bringing up the lo device fixed it.
You're not talking at all about why specifically you need this
(ie. your use case) when you are spinning up namespaces for users.
I do happen to know those details, but you need to talk about this
explicitly in your commit log messages and in this discussion so that
everyone else understands this as well.
Well, I can make this commit message long-winded but most of the (so
called) issues are well known and I thought I wont add any additional
value repeating them here hence kept it simple. I can spin up the next
rev with the long-winded commit message. ;)