Re: in kernel manual, should pick another example for KMACHINE

[Bruce Ashfield <bruce.ashfield@windriver.com>]

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-bounces@yoctoproject.org [mailto:yocto-
>> bounces@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 <rpjday@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