On Sun, 6 Sep 2009 21:40:19 -0400 Daniel Dickinson <[email protected]> wrote:
> On Sun, 06 Sep 2009 01:13:47 +0200 > Felix Fietkau <[email protected]> wrote: > > > Daniel Dickinson wrote: > > > Hi all, > > > > > > I've refreshed the patches to work with current trunk (as the old > > > patches were no longer applying cleanly due to recent changes). > > > There are also a couple of minor functional changes some of which > > > make the usb root stuff I'm working on easier. > > > > > > I'd really appreciate if there could be some review/comments on > > > these patches soon. It's been a significant period of time and I > > > haven't heard from full devs on what they think, although a couple > > > of list members like the idea of the modularization I have done. > > In principle, it looks useful. One thing I don't like that well is > > that every hook you add has to be a separate file > > in /etc/preinit.d/run.d I think it would be cleaner to have just > > an /etc/preinit.d with files that are sourced at the beginning of > > preinit, which can then add functions to various hooks that are > > defined by preinit. For instance the netmsg plugin would then do > > something like this: > > > > netmsg_send_message() { > > netmsg [...] > > } > > netmsg_send_init() { > > failsafe_ip > > netmsg_send_message "Press reset to enter failsafe now" > > } > > netmsg_send_enter() { > > netmsg_send_message "Entering Failsafe!" > > } > > > > add_hook init netmsg_send_init > > add_hook failsafe_enter netmsg_send_enter > > Hmmm...I'm not as fond of that solution because it is limited to > specific hooks. My solution is much more generic. It sources the > files in /etc/preinit.d/run.d/stage_* (at each stage) and then > executes the functions of the same name as the file. That means > packages can drop in new functionality without having to modify > preinit for additional hooks. I've used that for the failsafe > provider I have posted, and am using it for the usb root I am > created. Those options exist as packages. Without packages things > act as usual, with the packages there is a change in functionality > that wouldn't be possible with predefined hooks, unless you're > constantly updating the available hooks. Well, since you're the only one who's replied, and I've reread your reply and thought maybe I misunderstood you, perhaps I should make sure I understand what you mean. My concern is that I want to be able to drop in a package to modify the behaviour of preinit or failsafe, and then, when needed (I've used it already) to drop in another package that modifies that package that modifies preinit / failsafe. How would that look with your suggested solution? How does you solution go about adding arbitrary new functions that are called at the appropriate time in the boot sequence (I didn't follow that from your example, so maybe I'm not understanding what you mean). In the solution I presented the boot looks something like: 1) Stuff that happens always because it's in /etc/preinit 2) iterate through the files in /etc/preinit.d/conf.d (in lexical sort order) and eval the files (.e.g 01preinit.conf's variables of the form veriable=value are entered into the environment, then 02preinit.conf's variable=value, so that 02preinit.conf overrides 01preinit.conf, if they variable names are the same (otherwise it's additive)) 3) iterates through the files in /etc/preinit.d/run.d, sourcing the files in lexical sort order. It also builds up a list of filenames 1) This means that functions in 02preinit.run override functions in 01preinit.run, if different. 2) There can be an arbitrary number of functions per source file, the only hard requirement is that each source file have a function of the same name as the filename (see below) 3) If there are commands in the file that are not in a function they are executed in the order of the files being sourced. 4) iterates through the the list of filenames and attempts to execute functions with that name. That means that after the files have been sourced, and possibily overridden, that the 'hook functions (which are filenames)' are executed in lexical sort order. This gives the ability to add new functions anywhere in the sort order, as well as to override any function with a different version (including null-op functions) before they are executed. Is this possible with your solution and, if so, could you provide an example of how it would work? Or, if there is a way you could see to improve the way in which I achieve my desired goals, could you suggest it? Thanks! Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://cshore.is-a-geek.com
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
