[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: apex-nslu2-1.4.14



Martin Michlmayr wrote:
> * Rod Whitby <rod@whitby.id.au> [2007-02-05 07:21]:
>> Assuming this build of apex puts the environment in the same block as
>> apex itself, are the debian scripts padding that block with FFs or
>> zeros?  If the latter, that would explain it.
> 
> Ah, thanks.  I remember this discussion now.  Yes, it's padding with
> zeros.
> 
> Is the APEX environment supposed to be in the same mtd block as APEX
> itself?  Wasn't the original idea to hide it in the FIS directory?
> Once I know these details, I can try to integrate this new version
> properly (but that's after etch anyway).
> 
> Doesn't mean having the APEX environment in the APEX block mean that
> we overwrite user changes with each upgrade of APEX (at least if we
> simply wrote the new APEX binary to flash and padded it; I guess we
> could use more trickery and use apex-env to read the environment, then
> write APEX to flash and then set the environment again).

Yes, that's true.  How often do you think people will be updating apex
without flashing a new image (which would overwrite the fis directory
anyway)?

On the other hand, when flashing a new apex, it might be a good idea to
reset apex environment settings (or at least making the user review
them) in case there are incompatible changes in the environment format.

> Sorry, I'm aware that you and Marc had quite a bit of discussion about
> this, but I didn't follow the discussion at that time... I suppose
> we in Debian could just wait and then copy whatever nslu2-linux.org
> does. ;-)

I wasn't sure whether we'd come up with a final decision or not - we
were waiting for some proof of concept experiments and the Debian input
to determine the pros and cons.

I'm happy with it going in either spot.  I've left room for it after the
microcode in the FIS directory area - we would just update slugimage to
use that area.

-- Rod



Reply to: