Under development.
I'm currently in the process of further expanding the flexibility of the already flexible WDL initrd/init (whilst keeping its init size but a fraction of most others around the place).
Previous versions of WDL initrd/init catered for 100 overlayfs layers, which allows for tons of addon sfs modules I know. However, since kernel 3.1 the loop device limit is no longer really limited (they are now allocated dynamically as required - apparently up to theoretical 2^20). No doubt overlayfs itself has its performance limits, in terms of layers used, but as technology moves on I believe it is good practice to design for no limits or at least very high limits since most apparent 'limits' generally prove to be artificial in the end (as processing capabilities improve).
Fortunately a one-line code change allows WDL initrd/init to accommodate 1,000, or 10,000 or whatever sfs addon module layer numbers, so in newest code I'm simply using a base variable to specify the range required. Main reason is not that I expect to see hundreds of layers used in the near future (though you never know - tinycorelinux uses plenty of loop mounts as part of its design) but rather to allow for easier numeric range allocation (the larger the range is, the easier it is to allocate a range for save-changes rollback sfs module numbers for example without danger of running out of overlayfs layer numeric filename space). So in my next build I'll be testing with firstrib_rootfs at position 100firstrib_rootfs (rather than 01firstrib_rootfs) and with upper_changes_rollback sfs numbers starting at a somewhat arbitrary value of 200. That spacing makes it easy to add as many modules as perhaps reasonably wanted either below or above 100firstrib_rootfs (and hence not-overwriting or overwriting files as desired) whilst leaving tons of numeric range for upper_ranges rollback numbers (anything say in range 200 to 1000). (Any such base number choices are however entirely arbitrary and any WDL system builder can re-allocate as they wish). i.e. I'll be using NNN instead of NN (but with one line code change could use overall range of NNNN or more if ever that level of granularity proves useful in the future...).
That ability to scale is a major reason why I believe the numeric (NNN...) sfs module filename convention implemented in the WDL unique _addlayers algorithm is far superior to the likes of a limited adrv, bdrv, cdrv and so on alphabetic ordering convention (though of course it is possible to artificially assign/hack some kind of numeric alias, as a less than perfect fudge, to such generally difficult-to-scale non-ordered or simple alphabetical ordered layers types of system filesystem layer design).
Anyway, expanding the range scale (to any range desired) is a trivial change to the efficient _addlayers function in WDL init, but to complement that I'm expanding the w_changes mode capabilities to improve save changes functionality with a particular intention to make rollback handling easier to automate. The NNNupper_changes rollback files will also, for convenience, include date in their filename (though that won't be done in the init, but rather in separate rollback management utility). Having said that, I'm not personally so interested in the final implementation of the userland rollback utilities (could be commandline or GUI, for example, and lots of ways of doing that), but want to make sure the WDL_initrd/init provides sufficient facility to easily allow such schemes. User/developers will of course be able to write their own userland utilities to manage rollback and so on in whatever way they find most useful (but whatever method used does rely of course on whatever flexibility/functionality the core WDL_initrd/init layering scheme provides - which, fortunately, is quite a lot... and particularly with the easy text-based plug-in extension/modification capability it also provides).
Currently I'm coding additional w_changes options/modes: EXIT0, EXIT1 (already completed some while back) and EXIT2. I'll explain what these are all for later, but suffice to say they are concerned with management of what gets saved (e.g. out of RAM temporary store), and when, (including providing for easier management of changes rollback date-assigned snapshots). Sounds complicated, but actually only simple additions to existing initrd/init code though I am re-writing the logic of the existing w_changes code section involved since I can simplify it somewhat. Clearly will have a lot of testing to do thereafter prior to any public release so this is just an update in case anyone wonders if development is currently active or not - it very much is.
EDIT: In practice I'm planning to use "memory jogging" option names for EXIT0, EXIT1, EXIT2, and so on, to help indicate what they are used for (saves having to keep referring to documentation for more detailed reminders...).
Main thing I remain concerned with is not to break what already works so efficiently and well... there certainly won't be any significant bloat - the init only needs to provide all the core functionality, which is quite basic/fundamental really - external utility apps complete the job. Most important, for me, is that WDL initrd/init remains distro agnostic, which means basically decoupled from the main root filesystem used with it - that's why WDL can be used with most any other distro's root filesystem to provide WDL modular multi-layer addon capabilities.
wiak
