xiangfu wrote: > how about let qi read a file like qi.conf in SD card first > partition.(this file must in first partition)
Hmm, let's see what this could do. First the good features: - it would give the command line(s) a place to live - (kernel) file names no longer have to be hard-coded, e.g., one could make a kernel called "uImage-20080827", and point to it. This is a bit nicer than symlinks. (But see below for the downside.) - it would provide a means for the user to alternate between kernels on the secondary partition (my list of primary/secondary choices and fallbacks couldn't do that) - it would give more freedom for choosing which partition is second, e.g., it could be the third partition instead of the second one - it would remove policy (i.e., the sequence of things to try) from qi The not so good things: - more complex failure mode, i.e., if qi.conf cannot be found or is syntactically incorrect, what would qi do ? What if a file listed in qi.conf doesn't exist ? - there has to be a (small) configuration file parser - it would create a shared configuration resource, i.e., first and second partition would share the same file, even though they are otherwise independent from each other. (LILO and GRUB have that issue as well and nobody seems to be overly bothered by it, so perhaps this isn't such a big problem.) I would be mainly worried about the larger number of failure modes and their complexity, particularly if qi tried to be smart about it. I like the aspect of removing policy (= frozen configuration) from qi. - Werner
