netdev - Re: [PATCH 0/3] ipconfig tweaks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 17 Apr 2009 14:00:40 +0400
From:	Dmitry Krivoschekov <dmitry.krivoschekov@...il.com>
To:	David Miller <davem@...emloft.net>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH 0/3] ipconfig tweaks

David Miller wrote:

>From: dmitry.krivoschekov@...il.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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html