On Wed, 23 Mar 2011 11:32:51 -0400 Stefan Monnier <monn...@iro.umontreal.ca> wrote:
> >> > the disabling is being done deliberately to give users a chance / > >> > force them to clean up the overlay after a reflash. > >> So this test is only for the `overlay' case, not the new "option > >> target /" case, right? > > No, it's for both because the option target / case still has the > > same problem, namely incorrect kernel modules and possibly broken > > uClibc binaries after a firmware flash, so in both cases the user > > probably needs to update for the system to not brick after a > > firmware upgrade. > > I see there's indeed a problem for kernel modules (tho if you insmod > all the modules in squashfs+jffs before pivoting to the extroot, this > is not an issue), but for uclibc binaries I can't imagine how that > can be relevant in the non-overlay case. Picky, picky. ;-) Well other than binaries that depend on the kernel like iptables you should be right about the uClibc binaries. But the normal case (i.e. not custom) is to load the modules after extroot, so that's what we build extroot for. If you really care and want to submit patches that are suitably generic, we'll of course take a look at them. Unfortunately some good patches have been submitted that I was too busy to deal with, which were rendered obsolete by other, more pressing, changes. It'd be different if I didn't have to work to live, but I think that's a common complaint, so I shan't belabour the point. Regards, Daniel -- <erno> hm. I've lost a machine.. literally _lost_. it responds to ping, it works completely, I just can't figure out where in my apartment it is. GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
