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

RE: [Lsb-appbat] ia32 machine types in nALFS

> -----Original Message-----
> From: Stuart Anderson [mailto:anderson@netsweng.com]
> Sent: Tuesday, September 17, 2002 8:44 AM
> To: Wichmann, Mats D
> Cc: lsb-impl@lists.linuxbase.org; Lsb-Appbat (E-mail)
> Subject: Re: [Lsb-appbat] ia32 machine types in nALFS
> On Tue, 17 Sep 2002, Wichmann, Mats D wrote:
> > Now that the cond stuff works, we still
> > need an answer on the ia32 architecture,
> > where there are several different answers
> > given when asking what the machine type is
> > (i486, i686, others).  Smells to me like
> > those all ought to be equivalent from
> > the point of view of the xml.  How can
> > we accomplish this?
> I think my original idea of using uname() was bad. We should 
> probably just
> hard code the expected value using #ifdef __arch__ at compile time.

Sounds good... that way they can be the same as
__arch__ without having to do any remapping.
The only concern being that we need to update for
any new arch - trivial fix, but it's just one
more place to remember...

Who's going to drop in the fix?


I didn't add the postscript the way I promised.
So here it is...  

When nALFS is asked to run an element, it calls an
internal routine that walks down the tree below
that, and for each node, if it's "runnable",
marks it should_run.  If it's not runnable it
just returns, meaning that whole branch is pruned
out.  This logic matches the way the different
node types in the original code were defined.
The measure of "runnable" is either it's the
root node, a profile, or an element.  Everything
else is treated as not runnable - things like
parameters, comments, and entity declarations.
The definition of "element" is it has a handler
routine available.  The <cond> element is fine,
there's a handler for cond.  However, the
next step down, the <i686> <ia64> <default>
tags don't fit any of the above definitions
of a runnable element, so everything below that
was skipped - the individual condition cases 
never got run. 

So much for bending the design is ways it wasn't
originally meant to go....

Reply to: