On Mon, 2013-11-11 at 10:52 +0800, ChenQi wrote: > On 11/10/2013 07:00 AM, Phil Blundell wrote: > > 1. initscript doesn't obviously rdepend on busybox so it's not obvious > > that the latter will always be available; > > Yes. Initscript doesn't rdepend on busybox. But note it also doesn't > rdepend on sed or awk or grep. > So I think it's reasonable to assume the presence of busybox.
I think one could argue that it's also a bug that it doesn't rdepend on the three things you mentioned (and indeed on /bin/sh itself, for non-rpm systems). However, the usage of grep and sed in particular, and perhaps to a slightly lesser extent awk, is so deeply ingrained into so much software that I think it's probably fair to say those utilities will almost always be present. By contrast, it is perfectly feasible to build a system which doesn't use busybox (by using the full GNU implementations of everything that busybox provides) and indeed I think there might even be a task package in oe-core which does exactly that. So it seems entirely possible that /bin/busybox might not be installed unless you have a dependency on it. > > 2. it should probably be using ${base_bindir} and ${bindir} rather than > > hardcoding absolute paths. > > In init scripts, we usually "hardcode" things, because these scripts > are destined to run on target. > In recipes we try not to hardcode things because the recipe may need > to extend to "native" or "nativesdk". I'm not quite sure I follow the logic here. Even if the script is intended to run on the target it still ought to be respecting the values of ${bindir}, ${sysconfdir} and such like. > > 3. the whole idea of creating a shadow "/usr/bin" underneath what's > > meant to be a mountpoint seems rather dubious to me. > > Agree. > > The problem here is that the init scripts under /etc/rcS.d/ need to > execute commands like awk, dirname, and readlink which are from /usr. > > As it's not appropriate to move these commands into /bin, basically > there are only two options I can see here. One is to modify these > scripts to use only commands from /bin or /sbin; the other is to make > use of busybox, as busybox is located under /bin as it provides these > commands. > I chose to the latter one because I thought that solution would have > the less impact. > > What do you think? Do we need to modify the init scripts? Or any other > solution? 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. 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?) 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. p. _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core