On 05/30/2011 02:55 PM, Bruce Dubbs wrote:
> I'd appreciate it if you could do a revert. I took a look at the
patch and it installs initd-tools as yet another
> package. I looked at the source to initd-tools and I don't understand
why we need a C program to do that. It could
> be done in a shell script. That would require someeffort to create,
but would be much easier to maintain.
I'll jump in and fix that for now real quick then, I'll also add the
subsystem call to udev script, but IDK about scripting
{install,remove}_initd. Initd-tools is one extra package, it's tiny, it
works, and being only in C, the maintenance burden is likely to be very
small.
> Perhaps I can try writing the script after the middle of next month.
We have a big deadline coming up.
> After that, I think I've earned about a year of comp time.
I'll wish you luck then. ;-) Been there, done that. It was really slow
in just bash (and a couple hundred sed and grep calls), but was a neat
learning exercise none the less. For fun, I then wound up using make to
handle dependencies and the script was almost fast enough to be usable
(somebody had suggested using make as a replacement for init in some
passing conversation and I thought it a neat idea). :-) Then I decided
to use it as an excuse to learn perl. Dan came up with initd-tools
before I really even got started on it in perl (which I still do not
know well BTW). I thought C would be perfect (no additional dependencies
for LFS), so I scrapped all three previous attempts.
At any rate, here are a couple of caveats that I vaguely remember
causing me to start from scratch or make major changes to the way I was
doing things a few times:
1. Scriptname != Facility. Admittedly, this seems obvious now.
2. Do not fall into the trap of looking at /etc/rc.d/init.d and
expecting all scripts to be activated. The easiest method I came up with
for a list of activated scripts was to run through all of the rc?.d
directories to assemble a list of link targets. From that list, I then
read all of the headers into multiple arrays and worked only from the
index with the new script as the last in the array so that disk i/o was
limited to the beginning and end of the script.
3. Don't forget about start links in 0 and 6 which will be dependent on
both *-stop and *-start of the current runlevel, but not scripts
supplied in runlevel S (formerly sysinit).
4. All other runlevels will have to account for items started in
runlevel S.
5. The Default-St{art,op} does not have to define in which runlevels any
existing activated scripts are started, but both Dan and I, while
working independently, chose to do so as the spec does not limit the
program in that way, and the note at the bottom of
http://refspecs.linuxfoundation.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/initsrcinstrm.html
does not seem to indicate that will change. LFS does not provide any
existing automation, and in practice this is really the most direct way
of managing runlevel 4 if needed, and provides similar functionality to
insserv or chkconfig in Suse or RedHat without any added complexityor
additional tools(in fact, in all test cases that I could come up with,
it greatly simplifies the job to always reorder as opposed to trying to
fit a script in between others).
HTH
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
