From: Jeff Dike <jdike@ka...> - 2001-12-10 02:05:12
> Normally, the linker will place files and sections matched by
> wildcards in the order in which they are seen during the link.
I asked Keith Owens about this, and I was correct to gripe about fiddling
the Makefile ordering, but I was griping about it for the wrong reason.
He doesn't have a problem with link ordering determining initcall ordering.
What he doesn't like is Makefile ordering determining link ordering.
So, I'm not going to change that in order to make this work. I'll find some
other way to do it.
From: Jeff Dike <jdike@ka...> - 2002-04-15 17:49:55
> There are a few issues that prevent NFS root from working.
Not any more.
> 1) initcall: inet_init occurs before uml_net_init preventing us from
> registering our netdevice in time for ipconfig.
I'm not sure what the dependency there was, but it's no longer a problem.
I did add a bit of code to make sure that uml_net_init processes any IP
addresses that had already been assigned to the UML interfaces.
> 2) tap_open_common demands the initial open of the device to also
> specify an interface address.
This works a lot better now. I set the interface up with dhcp from the
nfs server (another UML communicating over uml_switch).
> 3) [net/ipv4/]ipconfig.c busy waits either side of the device open
> calls but jiffies remain frozen.
It turns out there was a period of time during the boot when the timer
wasn't ticking. This is fixed.
After this (and making sure that dhcp/bootp work), I can nfs boot one UML
off another. The one thing I didn't figure out is what to stick in fstab
or wherever else to get a clean boot. I ended up putting
192.168.0.253:/nfs / nfs defaults 0 0
which pursuaded fsck to ignore it, but it was mounted readonly, which screwed
the rest of the boot.