On Mon, Sep 16, 2013 at 06:54:55AM +0100, Maciej W. Rozycki wrote: > Thomas, what was the rationale behind arranging things in this way? Did > you mean to make this code shared among platforms needing it? I would I really can't remember the reasoning any more, but I guess code sharing was a reason. > guess so, but then the copy in arch/mips/dec/prom/ would have to be > removed and macros in <asm/dec/prom.h> adjusted according to the new API > which you didn't do in your change. because I didn't have a running DECstation handy. > Also why the need for stack > switching? It looks like an unnecessary complication to me, any firmware > callbacks exported have to maintain stack integrity or they would be > unusable. Is that to work around some SNI firmware quirk? a 64bit kernel with more than CKSEG0 addressable memory may end up having a stack outside of CKSEG0, which is something the 32bit SNI firmware doesn't like. I guess the same is true for DECstation, if there is a HW config with enough memory. > [And does it work for the SNI in the first place? -- it looks to me like > `o32_stk' has an alignment problem (8 is required for the stack pointer in > the o32 ABI though 4 will often be enough to satisfy hardware); but > perhaps it just happens to get correct alignment by virtue of merely > always following a data object that enforces it, hmm...] it worked, but nevertheless fixing the aligment isn't a bad thing. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessarily a good idea. [ RFC1925, 2.3 ]
