On 11/11/13, 5:53 AM, Phil Blundell wrote:
On Mon, 2013-11-11 at 10:52 +0800, ChenQi wrote:
On 11/10/2013 07:00 AM, Phil Blundell wrote:
...
I thought that last time this topic came up on the mailing list, the
eventual conclusion was that Wind River (being more-or-less the only
people who seemed to feel strongly that supporting / and /usr on
different partitions was important) were going to come up with some sort
of overall strategy for solving the whole problem rather than just
fixing up individual bits in a piecemeal fashion. I think that strategy
would need to include a policy for which utilities initscripts can
legitimately expect to be available before /usr is mounted, and if this
set is different from what we have today then it would need to include a
plan for sorting that out.
There is a bug open for the Yocto Project 1.6 to explicitly do this. Come up
with an overall strategy for these kinds of things, as well as a test plan to
verify that whatever we end up doing works properly long term.
As you said, busybox is not required on a system -- just something that has a
reasonable set of software packages. Also a lot of this stuff is simply limited
to 'early boot'. At some point we do need to define 'early boot'. (Generally I
define it as until /usr would normally be mounted.)
And unfortunately you will see patches in piecemeal at this point. Until such a
strategy is generated, everything is being done reactively. We see a QA
error/warning and someone is assigned to solve it. Yocto Project Compliance
(and our own internal) guidelines then indicate since we've patched something it
has to go out to the community.
To answer the particular question at hand it seems that someone would
need to do some analysis of things like:
- how many scripts actually need those commands
- how hard would it be to change them to not need them
- what would be the impact of moving them into ${base_bindir} (for
example, would this cause a whole load of libraries to get dragged into
${base_libdir} as well?)
That was my thought exactly. Lets look at moving things -or- stop using them.
Whichever is more reasonable.
Offhand I don't know the answer to any of those things.
4. this seems like distro policy and not something that really belongs
in oe-core at all. For systems where ${bindir} and ${base_bindir} are
on the same filesystem (or even are the same directory) this script will
just make bootup slower without achieving anything useful.
If /usr and / are on the same file system, this script has no real
effect because /usr will always be there. So I think it will not take
much time at boot.
Just spawning a new copy of the shell and reading the script does take a
finite (and measureable) time. If you can determine statically at build
time that the script isn't going to do anything useful then I don't
think it's appropriate to install it.
If ${base_bindir} and ${bindir} are the same, that means that there's
no /usr. In this case, there should no /usr/xxx entries
in /etc/busybox.links, so this script should also function correctly
and it will not take much time at boot.
(I just configured ${bindir} and ${base_bindir} to be the same and
performed a build, it failed. I'm not sure whether it's valid to make
such configurations in OE.)
It is a valid configuration, and this is the way that most of the images
I build are configured. It probably is true that there are still some
number of recipes in oe-core that don't support this properly, but I
don't want to see that situation get any worse.
And yes, all scripts need to (at build time) bind to the bindir and base_bindir
of that distribution. Hardcoding those values into the scripts before build
time is wrong.
--Mark
p.
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
