From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Darren Hart <dvhart@linux.intel.com>
Cc: Yocto Project <yocto@yoctoproject.org>
Subject: Re: linux-yocto: ktypes/tiny and some questions along the way
Date: Sat, 10 Dec 2011 01:53:51 -0500 [thread overview]
Message-ID: <4EE301FF.9040200@windriver.com> (raw)
In-Reply-To: <4EE2911E.3090708@linux.intel.com>
On 11-12-09 5:52 PM, Darren Hart wrote:
> Bruce,
>
> I'm looking at introducing a new kernel type, ktypes/tiny.
>
> Tiny will define a core set of kernel policy options, such as proc, sys,
> devtmpfs, futex, epoll, elf bin format, etc. It will not enable any
> drivers, filesystems, debug options, or networking options by default.
> This would be the responsibility of the BSP to add a named feature
> implementing this.
>
> Taking a look at the ktypes we have now resulted in some questions:
>
> dvhart@envy:~/source/linux/linux-yocto-3.0/meta/cfg/kernel-cache/ktypes
> $ tree
> .
> ├── base
> │ ├── base.cfg
> │ ├── base.scc
> │ ├── hardware.cfg
> │ ├── hardware.kcf
> │ ├── non-hardware.cfg
> │ └── non-hardware.kcf
> ├── preempt-rt
> │ ├── preempt-rt.cfg
> │ └── preempt-rt.scc
> ├── standard
> │ ├── perf-force-include-of-stdbool.h.patch
> │ ├── perf-hard-code-NO_LIBPERL-NO_LIBPYTHON.patch
> │ ├── standard-patches.scc
> │ ├── standard.cfg
> │ ├── standard.scc
> │ └── x86-add-TIF_32BIT-compatibility-define.patch
>
> These form a hiearchy, each inheriting from the layer beneath like so:
>
> base/standard/preempt-rt
>
> As I dig into this I see that some policy is infact laid down by base,
> including things like:
>
> CONFIG_MODULES=y
> CONFIG_INET=y
> CONFIG_PREEMPT=y
> CONFIG_NFS_FS=y
> CONFIG_MSDOS_PARTITION=y
>
> These pull in the IP stack, the block layer, etc. Because of this, I
> can't really inherit from base for ktypes/tiny. I would like to inherit
> the hardware and non-hardware kcf files though, as well as any patches
> that might make their way into base. Which leads me to standard. I would
> like to see a much smaller set of config policy options set in base.
> Most likely these should be exactly what we agree on for tiny, and tiny
> wouldn't add any additional policy as it implements only what is
> required for a Yocto Project built kernel.
>
> NOTE: kernel version is 3.0+
> $ cat base/base.scc | head -n 1
> set_kernel_version 2.6.37
>
> There are three patches in standard, only two of which (the perf ones)
> are listed in the standard.scc. As I believe any kernel we build should
> have these, I would like to see any global patches applied to base,
> leaving standard to define policy, and include named features.
>
> With these changes, I could add ktypes/tiny as follows:
> $ cat tiny/tiny.scc
> include ktypes/base
> branch tiny
> include features/xyz/xyz.scc
> include cfg/abc.scc
>
> Another point of interest is preempt-rt, as I can see people wanting to
> build tiny preempt-rt. I think the best approach here is to create
> ktypes/tiny/preempt-rt-tiny/preempt-rt-tiny.scc.
>
> Note: I believe this fails with .patch.patch
> $ cat features/rt/rt.scc | grep patch
> patch rt-apply-patch-3.0.10-rt27.patch.patch
>
> I'm working on a patch series that implements the suggestions I've made
> above. Bruce, do you have any issues with this approach?
FYI: I have a response to this .. but it's just not reading very well here.
And it's late, so I'm going to respond over the weekend when I get a
chance to revise what I've written into something legible. :)
Cheers,
Bruce
>
next prev parent reply other threads:[~2011-12-10 6:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-09 22:52 linux-yocto: ktypes/tiny and some questions along the way Darren Hart
2011-12-09 23:09 ` Darren Hart
2011-12-10 1:05 ` Darren Hart
2011-12-10 6:53 ` Bruce Ashfield [this message]
2011-12-12 5:14 ` Bruce Ashfield
2011-12-12 23:17 ` Darren Hart
2011-12-14 16:59 ` Bruce Ashfield
2011-12-14 18:07 ` Darren Hart
2011-12-14 18:43 ` Bruce Ashfield
2011-12-14 19:06 ` Darren Hart
2011-12-14 19:13 ` Bruce Ashfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EE301FF.9040200@windriver.com \
--to=bruce.ashfield@windriver.com \
--cc=dvhart@linux.intel.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.