netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Krivoschekov <dmitry.krivoschekov@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 0/3] ipconfig tweaks
Date: Fri, 17 Apr 2009 14:00:40 +0400	[thread overview]
Message-ID: <49E85348.8080906@gmail.com> (raw)
In-Reply-To: <20090417.012316.209396377.davem@davemloft.net>

David Miller wrote:

>From: dmitry.krivoschekov@gmail.com
>Date: Thu, 16 Apr 2009 13:37:36 +0400
>
>
>>this patch series adds some flexibility to ip_auto_config() function.
>>Currently the function assumes that 500 msec delay before opening
>>a network device is enough, but it's not true for some h/w configurations,
>>e.g. if you're using a USB network device. 
>>In my case it may take up to 2 seconds before the device gets available 
>>for opening.
>>
>
>I think this problem space would be served better by a scheme
>that just worked automatically.
>
yes, sure, and my third patch tries to add such a scheme:
http://www.spinics.net/lists/netdev/msg94723.html

while the first two patches can be considered separately:
http://www.spinics.net/lists/netdev/msg94724.html
http://www.spinics.net/lists/netdev/msg94726.html

as the patches allow you to change that pre-defined delays, i.e. you
can adjust the delays for your particular system. As I wrote it could
save about 1 second of boot-up time.

>
>If the user put nfsroot= onto the kernel command line, the expectation
>is that the device is expected to be there.
>
>
Agreed.

>Therefore it is reasonable to make the ipconfig.c code do a loop
>periodically retrying to open the intended network device.  And after
>several seconds of iterations, fail.
>

Why it should fail? What do you expect from the system to do when it fails?
It gets unusable anyways and you'll have to reboot it again. But, if it will
be infinitely looping, there is a chance it finds something suitable :).
If you're sure it won't find anything then reboot it and configure it 
properly.
In fact, DHCP code can loop infinitely (see "try_try_again" loop).

>
>Heck, it doesn't even need to do anything fancy.  After the initial
>attempt, it can simply wait for the NETDEV_REGISTER notifier event.
>Then it will know exactly when the device shows up.
>
>In fact you won't need anything to implement this, simply register the
>notifier and make the notifier trigger the ipconfig.c code to do a
>DHCP or RARP probe or whatever when the device we're interested in
>appears.
>
>
ok, I'try it

>I'm not applying these patches, sorry.
>

As I wrote above, the first two patches can be considered separately.
Why don't let users to optimize boot-up time?


Thanks,
Dmitry


  reply	other threads:[~2009-04-17  9:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-16  9:37 [PATCH 0/3] dmitry.krivoschekov
2009-04-16  9:37 ` [PATCH 1/3] ipconfig: use same time units for CONF_{PRE,POST}_OPEN delays dmitry.krivoschekov
2009-04-16  9:37 ` [PATCH 2/3] ipconfig: add 'ipwait' cmdline parameter dmitry.krivoschekov
2009-04-16  9:37 ` [PATCH 3/3] ipconfig: look for a network device forever if NFS root dmitry.krivoschekov
2009-04-17  8:23 ` [PATCH 0/3] David Miller
2009-04-17 10:00   ` Dmitry Krivoschekov [this message]
2009-04-17 10:45     ` [PATCH 0/3] ipconfig tweaks David Miller
2009-04-17 14:31     ` Benny Amorsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49E85348.8080906@gmail.com \
    --to=dmitry.krivoschekov@gmail.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).