On Tue, Sep 22, 2009 at 07:00:12PM +0100, Phil Blundell wrote: > On Tue, 2009-09-22 at 12:42 -0400, Denys Dmytriyenko wrote: > > On Tue, Sep 22, 2009 at 02:28:32PM +0100, Phil Blundell wrote: > > > On Mon, 2009-09-21 at 18:39 -0400, Denys Dmytriyenko wrote: > > > > On Mon, Sep 21, 2009 at 08:45:06PM +0100, Phil Blundell wrote: > > > > > It seems like there must be a better way of solving this problem. How > > > > > about just teaching "ifup -a" to spot interfaces that are already up > > > > > and > > > > > leave them alone? > > > > > > > > Won't work for the case of kernel-acquired DHCP address, i.e. kernel > > > > level > > > > autoconfig, aka IP_PNP, aka ip=dhcp command line. > > > > > > True, but your original patch won't help with this situation either > > > (since "ip=dhcp" won't match the regex). I think this is a different > > > > Not true. The default is to start udhcpc always. I just cover one case to > > prevent it from starting when ip=x.x.x.x > > Right, but as you said in your other mail, in the case where the kernel > has already claimed a dhcp lease you want to start udhcpc with different > arguments to the usual ones. So, although your original patch > admittedly doesn't make that situation any worse, it also doesn't make > it much better either.
Correct. As I was thinking on adding the check for kernel acquired DHCP lease somewhere inside the udhcpc code or script, it appears to be quite independent from this patch to pre-up... > I still think that this: > > > > problem and probably requires a different solution: the ideal thing > > > would be for the kernel to set a flag on the interface to say that it > > > needs to be taken over by a DHCP client, or alternatively to invoke the > > > DHCP client itself via the hotplug mechanism. Failing that you could > > > arrange for the startup scripts to poke around at /proc/cmdline and try > > > to second-guess what the kernel has done, although that would be rather > > > less satisfactory. > > together with the thing I mentioned earlier, is the right way to solve > this kind of issue in general. > > Poking at /proc/cmdline from the pre-up command has another downside as > well, namely that if you bring the interface down it will then be > impossible to get it back up again because the command line will still > have the "ip=" bits in it even though they are no longer relevant. Fair enough, I will try to figure out a better way of fixing it for all the possible cases... Thanks. -- Denys _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
