On 15-03-05 11:56 AM, Rifenbark, Scott M wrote:
I like Nathan's suggestion for the text.  Can someone explain to me though why emenlow is 
not a good example here?  In the linux-yocto_3.14.bbappend file, KMACHINE_emenlow-noemgd 
is set equal to "emenlow".  Isn't this equating emenlow-noemgd and emenlow?  I 
am probably mis-understanding it so I could use some further explanation.


The example was a good one, the issue that is being mentioned is
simply that meta-intel has removed the emlow* machine definitions,
so there's no code to use as a concrete addition to the docs.

Bruce

Thanks,
Scott

-----Original Message-----
From: yocto-boun...@yoctoproject.org [mailto:yocto-
boun...@yoctoproject.org] On Behalf Of Nathan Rossi
Sent: Thursday, March 05, 2015 5:48 AM
To: Robert P. J. Day
Cc: Yocto discussion list
Subject: Re: [yocto] in kernel manual, should pick another example for
KMACHINE

On Thu, Mar 5, 2015 at 10:03 PM, Robert P. J. Day <rpj...@crashcourse.ca>
wrote:

   in section 3.2 of the kernel dev manual, there is a discussion of
KMACHINE and how it is *typically* set to the same value as MACHINE,
but there are cases where that might not be true; however, the example
used to demonstrate this -- emenlow and emenlow-noemgd -- doesn't
seem
appropriate as there is no "emenlow" machine definition file anymore
in meta-intel. AFAICT, all of those non-noemgd machine definitions are
gone.

   in all the layers i have checked out, the only layer where i see
KMACHINE covering a number of MACHINE values is meta-xilinx
(zynq-based machines). it sounds picky but, when demonstrating some
concept, i think it's important that examples used actually exist in
the code base in case people want to check.

It comes around a bit due to the nature of different types of hardware. You
will find that amongst most of the meta-* bsp layers there exists two types of
MACHINE. You have the layers like meta-xilinx, meta-ti, etc which have
machines for each board. And then there are the layers like meta-intel which
have machines for each platform or SoC. There are a number of reasons for
each way.

At least for Zynq, the kernel can (if you ignore that it has FPGA
logic) be configured and built the same way for all the boards with device
trees handling the differences. And as such the configuration is setup for the
SoC instead of the board. The reason that you actually see KMACHINE
differences in meta-xilinx is that the layer uses the linux-yocto build flow as
well as providing an in layer config cache for its targeted KMACHINE's. Which I
believe is rarely done in bsp layers that inherit linux-yocto for their kernels 
(or
bbappend to linux-yocto).

You could re-word the documentation to cover this case with something like:
"This variable is typically set to the same value as the MACHINE variable
however in some cases may instead refer to the underlying platform of the
MACHINE."

Regards,
Nathan


rday

--


===========================================================
=============
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                         http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday

===========================================================
===========
==
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Reply via email to