[linux-yocto] [PATCH 1/1] [KERNEL] meta: Crystal Forest Machine Created.

[Bruce Ashfield]

On 12-08-08 02:35 PM, Darren Hart wrote:
>
>
> On 08/08/2012 11:32 AM, Bruce Ashfield wrote:
>> On 12-08-08 02:11 PM, Darren Hart wrote:
>>>
>>>
>>> On 08/08/2012 10:56 AM, kishore.k.bodke at intel.com wrote:
>>>> From: Kishore Bodke<kishore.k.bodke at intel.com>
>>>>
>>>
>>>> +++ b/meta/cfg/kernel-cache/bsp/crystalforest/crystalforest.scc
>>>> @@ -0,0 +1,21 @@
>>>> +kconf hardware crystalforest.cfg
>>>> +
>>>> +include cfg/x86_64.scc
>>>> +include cfg/8250.scc
>>>> +
>>>> +include features/power/intel.scc
>>>> +
>>>> +#These are required features for Intel DPDK Support
>>>> +include features/uio/uio.scc
>>>> +include features/hugetlb/hugetlb.scc
>>>> +include features/ixgbe/ixgbe.scc
>>>> +include features/igb/igb.scc
>>>> +
>>>> +
>>>> +include features/latencytop/latencytop.scc
>>>> +include features/profiling/profiling.scc
>>>> +include features/usb/xhci-hcd.scc
>>>> +include features/usb/ehci-hcd.scc
>>>> +include features/usb/ohci-hcd.scc
>>>> +include cfg/usb-mass-storage.scc
>>>> +include cfg/boot-live.scc
>>>>
>>>
>>> These last two should be in the standard and preempt-rt scc files and
>>> not in the base crystalforest.scc. The reason being, the kernel type
>>> should define policy - and whether or not we support mass storage and
>>> live boot is a matter of policy, not hardware enablement. The tiny
>>> kernel should not be required to pull in usb mass storage, fat support,
>>> etc to boot this machine.
>>
>> (moving to linux-yocto).
>>
>> Agreed on this, that the policy should be out of the BSPs.
>>
>> There are other fragments to move around as well, which I'm currently
>> looking at.
>>
>> Here's the question, do we want this for all boards, all arches, or do
>> we want some sort of intermediate x86/intel feature that defines this
>> policy, and the BSPs include that ?
>>
>> Either way works, and I'm inclined to move this to standard/rt as well,
>> but I wanted to gather some other opinions as well.
>
> For the purposes of Kishore's patches, I'm just looking for it to be
> consistent with what's in the tree now.

argh. I misread your comments. You are talking about the kernel-type
variants of the *machine* .. not the main ktypes!

So yes, this is bang on.

>
> For the long term, we shouldn't have to duplicate usb-mass-storage and
> boot-live for every x86* BSP for both preempt-rt and standard. However,
> we don't want that for the PPC, ARM, and MIPS machines, as far as I
> understand it, as we don't have live images (hddimg) for them anyway.
>
> Whether an hddimg is a valid image type or not is machine specific, so
> I'm not sure there is a better (and still correct) way to describe it
> than what we do currently (but I'd like to be wrong).

Agreed. We can change this in the future. I wasn't really looking
forward to trying to shuffle this around today anyway :)

Cheers,

Bruce

>