Init Scripts

Ken Moffat zarniwhoop73 at googlemail.com
Fri Feb 5 16:34:26 PST 2010


On 5 February 2010 16:14, Hops Error, Line 21, alcoholi.c
<from_blfs.10.defermentmullkegmalt at spamgourmet.com> wrote:

> But there are two parts of the Linux OS that have always eluded me:
> init scripts, and device drivers. Obviously question two, being a dark
> art some people have devoted their lives to, is well beyond the scope
> of something I'd ask here. But the thing is, as hard as they are to
> read and as much jumping back and forth one has to do, init scripts
> are just that-scripts. Undocumented, illegible (to me) scripts, but
> scripts nonetheless. Sure, some of them make sense; I've altered my
> fair share and even wrote a couple. Yet no matter how hard I try, I
> always run into a wall where something just does not make sense and I
> can't find the answers online anywhere. Or I'll find an answer, in the
> form of a recipe I don't understand.
>

init scripts tend to be distribution-specific.  For {B,}LFS, they have always
been fairly minimal (in some cases because there aren't enough users
to create the depth of problems that big distros see).

In general, it's often easier to diagnose specific problems.  So, for
example, if one of your own scripts used to work but now breaks,
the first step is to find out what has changed.  Unfortunately, as soon
as you delve into sysfs you are looking at things which tend to change
across kernel releases.

As I said, problems during boot can be difficult and tedious to
diagnose.  As well as luck in understanding the scripts, I'll wish you
a lot of patience!

>
> So no, I don't have an iludium pu 36 explosive space modulator hooked
> up to my laptop or anything. I like the way you think though :p
>

 Relieved to hear it, some of the early versions of those
are reputed to have more (hardware) errata than you can
shake a stick at.

 But seriously, device drivers are for physical hardware and
run in kernelspace.  If you are up to that, best of luck.  The
big problem is that anything not merged into the kernel is
forever trying to play "catch up" to get to a state where it
can be merged.   Unfortunately, LFS can tell you almost
nothing about how to write kernelspace code.

To understand a device driver, the requirements are perhaps:
- understand the hardware (documentation, particularly errata,
e.g. I had a ppc mobo with a b0rken chipset that seemed to
mostly work until a newer kernel incorporated necessary
fixes for errata. Those fixes highlighted the b0rkenness).
- understand the constraints of kernel coding (e.g. Robert Love's
book (I forget the title)
- understand the interface which the kernel provides (or else,
be able to persuade influential kernel hackers why you need to
add or extend an interface)
- and to maintain it, be aware of what is changing in the kernel.

ĸen
-- 
After tragedy, and farce, "OMG poneys!"



More information about the blfs-support mailing list