Re: [PATCH 2/8] initscripts: add setup-commands.sh

[Mark Hatle <mark.hatle@windriver.com>]

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
>