>> > This has to be manually configured after the first
>> > boot (and requires a reboot after a sysupgrade first boot).
>> Hmmmm... that's a problem.  It means that you can't just have
>> squashfs+extroot but need a jffs2 inbetween just for this
>> little cconfig.
> Actually the squashfs/jffs2 is a fallback full firmware in the event of
> Inevitable Disaster(tm).

Still, you need jffs2 there (both the jffs2 partition and the jffs2
modules).  That's a lot of flash space for something that's not
actually needed.  And of course, it's also an added step when
installing upgrading the firmware.

>> > config 'modules' 'modules'
>> >     list 'fs_modules' 'fs-ext3'
>> >     list 'controller' 'usb-core'
>> >     list 'controller' 'usb-ohci'
>> >     list 'controller' 'usb-storage'
>> 
>> In my (limited experience), "load all the available modules" works just
>> dandy: after all, these are only the modules available in the
>> "proto-root" filesystem, so they're likely to be pretty close to the
>> bare minimum.
>> 
>> Could you explain the rationale for the relatively sophisticated config
>> of modules you're proposing here?
> actually, the squashfs is likely to contain much more than the bare
> minimum;

Why?  If your rootfs is on USB or some such, there's little point in
including lots of stuff in your squashfs.

> it's got whatever the user menuconfig selects as their base
> router configuration and it's harder to do something about things going
> wrong in preinit, so minimizing the modules loaded is useful.  In
> addition hotplug doesn't coldplug in init.  That means hotplug events
> aren't generated unless the modules are loaded after hotplug
> (in /etc/init.d/boot).

I'll take your word for it on these issues.  They haven't affected me,
but that's not statistically significant.

> And, finally, it's really not very sophisticated.  It just loads modules
> if they're listed, the same was as load_modules for the main system
> does, except it loads specific modules instead of all available.

Well, I'm looking at it from the point of view of a user who'd like to be
able to directly tell "make menuconfig" that his rootfs is on /dev/hde1,
in which case any configuration on top of "the rootfs device name" is
an annoyance.

> It's not terribly complicated code in my opinion, so shouldn't be a
> problem.

I meant complex for the user, not for the implementer.
I mean, as a user, I've already had to select which modules to include
in my squashfs so that my rootfs can be found, so writing this file is
an annoyance, and will hold redundant info, except that I additionally have
to figure out whether it should say "fs_modules" or "controller" or
maybe something else.


        Stefan

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to