Re: Generic communication of boot loader state to the OS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Tue, Aug 26, 2014 at 3:02 PM, Russell King - ARM Linux
<linux@xxxxxxxxxxxxxxxx> wrote:
> On Tue, Aug 26, 2014 at 02:39:45PM -0400, jonsmirl@xxxxxxxxx wrote:
>> On Tue, Aug 26, 2014 at 2:28 PM, Russell King - ARM Linux
>> <linux@xxxxxxxxxxxxxxxx> wrote:
>> > On Tue, Aug 26, 2014 at 12:10:00PM -0400, jonsmirl@xxxxxxxxx wrote:
>> >> As a side effect this will eliminate the need for kernel command line
>> >> parameters describing boot state. Like console="". Over time it might
>> >> even be able to pass a DHCP IP address from uboot into the kernel.
>> >
>> > Err no.  Don't even think about that.  DHCP may be wonderful and all,
>> > but there's a fundamental issue with it: entries time out unless they
>> > are renewed.
>> >
>> > Why is that a problem?  Well, take a DHCP server which hands out
>> > dynamic addresses, and updates the DNS.  When the lease expires, it
>> > tears down the DNS entry.
>> >
>> > Now take a target booting using DHCP in uboot, which then mounts its
>> > root NFS.  If it tries to startup a DHCP client, the first thing the
>> > DHCP client does is to clean up the interface... resulting in it
>> > killing the root NFS connection.  If that doesn't happen, then you
>> > end up with a problem at shutdown, because DHCP clients always
>> > deconfigure the interface when they're killed off - resulting in
>> > "reboot" not being functional.
>>
>> I run the same configuration  -  uboot in flash, tftp to load kernel,
>> nfs mount the root. And I do reboot fifty times a day too.  I just put
>> everything on static IPs to avoid problems.
>>
>> Would this work if the DHCP client was notified that there already was
>> an IP lease in place?  It could remember that lease and then be
>> responsible for setting it into the interface and renewing it. Right
>> now there is no way to pass this information.
>>
>> Doesn't the DHCP client do the wrong thing simply because it lacks the
>> info to do something better?
>
> It can get the already configured IP address if the kernel (or initramfs)
> has already configured the interface - it's already available from the
> interface itself.  So it's not that there's no way to pass this to DHCP,
> it's that DHCP always starts out assuming that it's the new kid on the
> block.
>
> Solving that problem doesn't get away from the shutdown problem though.
> You can partially avoid it by not having interfaces brought down, but
> one of the things that distros commonly do is kill all processes during
> shutdown... which kills the DHCP client, and then causes the interface
> to be deconfigured... which then stalls the reboot operation because
> suddenly the root-NFS server is no longer available... Gosh, why did
> that happen I wonder...

I wonder if DHCP client couldn't be replaced with a udev event. Set a
timer in the kernel for the length of the lease. Then generate a udev
event when it is ready to expire. Udev event runs an app that gets a
new lease.  Now there is no process to kill on reboot and everyone is
happy.



>
> --
> FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
> according to speedtest.net.



-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux