Dear Graeme Russ, In message <calbutclvdsigmpwt04+-aqpdvj_zx9zzkbxh+ifcsxdxabd...@mail.gmail.com> you wrote: > > > Can we get rid of the 'f' parameter? If we invent a prerequisite > > called 'relocated' or something like that, to act as a barrier, then > > maybe the order can be defined just like any other function which > > depends on being before or after something? > > Well I kind of like see that a particular init function is explicitly a > pre- or post- relocation function. But yes, having barrier pre-requisites > would achieve the same effect.
I like the idea of having general synchronization (or barrier) entries, instead of pre- or post relocation, especially when considering the case of different configurations with or without SPL code or with externel pre-loaders or ... > > I wonder what happens when you skip something - does it substitute for > > any pre/post-requisites that the skipped item had? Or would that be > > illegal? > > SKIP_INIT(foo) simply removes all 'foo' init functions from the list > _after_ the list has been created - If this breaks dependencies that's > your problem ;). It is up to you as the 'skipper' to make sure that you > add init functions to allow things to still work Isn't that always the case? The functionsprovided by the user must perform their task - the dependency checking can only test the exitence of the function that claims to provide a specific property, but it cannot check if it actually does so. > With this proposal, if a board wants to entirely re-write the init > sequence, it can add a whole bunch of SKIP_INIT(blah) and then add it's > own INIT_FUNC(init_func, "myboard_bar"...) and nobody else will be the > wiser as to what is going on. The problem the is if the arch adds a new > init step, it may not be covered by the skip list by that board - tough, > lesson learn't for being so esoteric ;) We do something similar to the implemetnation of CONFIG_CMD_ and offer a way not to include the default init list at all. > > Anyway, it sounds very promising. > > Yes, it's a lot better than my original proposal :) It's fun to see this grow. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de A fail-safe circuit will destroy others. -- Klipstein _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
