Jeremy Katz wrote:
On Sun, 2007-08-12 at 23:13 -0500, Douglas McClendon wrote:
> I have a few changes I'd like to request to mayflower. I'd like to get
> some feedback before actually laying down the effort of producing patches.
So from a big high-level point of view, I'd really rather _not_ add lots
more that people depend on from mayflower. Having two different
codebases to handle the initramfs (mayflower + mkinitrd) is incredibly
painful for having to adapt both for changes in the OS, etc.
I agree that it would be cool if mayflower got absorbed into mkinitrd
(or vice versa). But that seems a litte far off right now, wheras the
changes I presented were all very small, and only served to structure
mayflower in a better way, which I imagine would make it's absorbtion
into mkinitrd easier, not harder. I.e.
#1 - this can be used to replace all that ugly cp /bin/stuff bin/ with
an elegant FILES= syntax in the existing mayflower.conf
#2 - as you agreed, just makes sense to not hard-code /etc/mayflower.conf
#3 - consider how my reply (--program) would be implemented, i.e. by
creating scriptlets in variables that get conditionally expanded in the
inline init creation. This sort of method of modularizing what gets put
in the init (think the OLPC specific parts, and everything else), makes
it much more elegant.
And given that overall mkinitrd "does more", I think it's going to be
better to get the live image specific stuff integrated into mkinitrd
rather than spending a lot of time making mayflower more flexible for
the sake of flexibility.
But to comment on the concepts...
> #1 - mayflower.conf - add PROGRAMS and FILES
> FILES+= would differ from PROGRAMS, in that the auto shared library
> dependency check would not apply to them. Maybe that doesn't matter,
> and you could just have FILES.
Having two different lists is just asking for people to pick the wrong
one. Since I can't think of a real reason that you'd want a binary
without its deps, just lump them together.
> #2 - support user specified mayflower.conf location
> (i.e. not just /etc/mayflower.conf)
Not terribly against or for this. Having the ability to specify config
locations is often useful enough for writing test cases that it's
> #3 - optional program, sort of like existing shell cmdline arg
> Have a cmdline argument of program= and eprogram= which would cause the
> specified program to be executed. program= would happen right after the
> current shell, and eprogram would happen right after the current eshell.
Why not just use init= ? Other than the fact that doing so is currently
broken with mayflower (... see above comments about two implementations
of the same thing :-)
The reason is that I very much like all the mayflower generated init
stuff that happens up to the point of the existing shell escape. I.e.
setting up an environment where bash can run and I can see my devices.
By specifying my own init, I'd basically be duplicating the mayflower
init generation code, except with my program= escape point, at which
point... hey, I'm back where this proposal started.