[Clfs-dev] Noticed a few trivial rough spots in CLFS embedded

[nu shto]

On Tue, Oct 22, 2013 at 8:03 AM, Andrew Bradford <
andrew at bradfordembedded.com> wrote:

> On 10/21/13 17:22, nu shto wrote:
> > Just one stylistic comment: I think it'd be worthwhile to point out how
> the
> > gcc-final build differs from the gcc-static build. I know it is pointed
> out
> > in the introduction, but it might be helpful to reiterate what is going
> on.
> > I found myself pausing to make sure that there wasn't just a problem in
> the
> > book since I had just built gcc and now I was suddenly building it again
> > with what appeared to be an identical procedure (it's hard to mentally
> diff
> > long strings of configure flags).
>
> Yes, that's a good idea.  Basically, you build GCC the first time so
> that you can cross build the libc.  Then you build GCC again, using that
> cross built libc, so that you can build userspace software (ie:
> everything except libc, kernel, and bootloader).
>
> If I add something like that, does that make it more clear?
>

Yeah, I think something along those lines should be sufficient.  I think
any cue to the reader (other than the title) that this set of instructions,
while similar, is in fact different than the previous step, would be fine.

Looking back, I think maybe the other reason why I found it confusing is
that the build directory names for both GCCs are the same (later I realized
that the assumption is that you have to delete the old build folder once
you're done with it).

Compiler bootstrapping is one of those magical things in computers that I
understand rationally but still makes my brain hurt slightly.


> > Also, a few trivial writing problems:
> >
> > $ git diff
> > diff --git a/BOOK/bootable/common/kernel.xml
> > b/BOOK/bootable/common/kernel.xml
> > index d227fa2..e2acf5b 100644
> > --- a/BOOK/bootable/common/kernel.xml
> > +++ b/BOOK/bootable/common/kernel.xml
> > @@ -45,7 +45,7 @@
> >          components are console/video, disk, and network. With out these
> > built
> >          in, the system will not function properly. It is recommended to
> >          configure the kernel without modules in order to conserve disk
> > space
> > -        and to simplify.</para></note>
> > +                 and to simplify (the boot process, or ...
> > what?).</para></note>
>
> I didn't have a good next word so I put a period :)
> Not having modules makes things less complex.  Got any recommendations?
>
> The main thing is that building and installing modules may require you
> to then have an initramfs, modprobe configuration, deal with u/mdev,
> etc.  I want to avoid explaining all that as it's not needed on an
> embedded system, usually.  Just build a kernel and boot it.
>

This is why my first thought went to "... simplify the boot process" --
because dealing with initramfs and modules seriously reduces the chances of
a novice getting their kernel to even boot. And if you can't get it to
boot, I feel like you're much more likely to just give up on the whole
thing. Perhaps something along the lines of "... and to eliminate several
module-related steps that, if done incorrectly, can prevent the kernel from
booting."

or perhaps more simply:

".... and to reduce the amount of configuration necessary to boot the
kernel."


>
> > diff --git a/BOOK/materials/common/creatingbuilddir.xml
> > b/BOOK/materials/common/creatingbuilddir.xml
> > index 0f809de..54f1c6c 100644
> > --- a/BOOK/materials/common/creatingbuilddir.xml
> > +++ b/BOOK/materials/common/creatingbuilddir.xml
> > @@ -19,7 +19,7 @@
> >
> >  <screen><userinput>export CLFS=/mnt/clfs</userinput></screen>
> >
> > -  <para>Ensure that this new directory has permissions that are too
> > restrictive
> > +  <para>Ensure that this new directory has permissions that are not too
> > restrictive
> >      such that you can write to it as a non-root user.</para>
> >
> >  <screen><userinput>chmod 777 ${CLFS}</userinput></screen>
>
> Thanks! Applied to my local git, will go with next pull req (probably
> later today).
>
> -Andrew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clfs.org/pipermail/clfs-dev-clfs.org/attachments/20131022/51c22b73/attachment-0001.htm>