> On Mon, Aug 01, 2005 at 09:47:54PM -0500, [EMAIL PROTECTED] wrote:
>> > [EMAIL PROTECTED] wrote this message on Mon, Aug 01, 2005 at 12:29
>> > -0500:
>> >> This has the result of reducing the size of the shell code, and
>> reducing
>> >
>> > Unless you cross a fs frag (usually 1024 bytes), i.e. reduce the
>> scripts
>> > by an average of 512bytes *per* script, you will see no disk space
>> savings
>> > from these changes... considering that on my 5.4-R system over half
>> > (73 of 124) are under a frag in size, it isn't that much...
>> >
>> > One thing that would be really useful for rc.d system is a way to
>> cache
>> > the ordering on boot... On a slow system like a 200mhz arm, the rc
>> > ordering can take a long while....
>> >
>> > --
>> > John-Mark Gurney Voice: +1 415 225 5579
>> >
>> > "All that I will do, has been done, All that I have, has not."
>> >
>>
>>
>> Ok thanks for the dirrection. Ask and thy shall receive. well a quick
>> hack
>> at least to implement cache of rcorder, although from my tests even on
>> old
>> hardware rcorder is quick. I wrote this in (cring) the long-spelled out
>> way. Anyways... don't forget to add the essential rc.conf knobs for the
>> two variables shown bellow.
>>
>> [root@:/etc]# diff -u rc rc.new
>> --- rc Sun Jul 31 17:45:19 2005
>> +++ rc.new Mon Aug 1 21:42:12 2005
>> @@ -72,7 +72,17 @@
>>
>> skip="-s nostart"
>> [ `/sbin/sysctl -n security.jail.jailed` -eq 1 ] && skip="$skip -s
>> nojail"
>> -files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null`
>> +# check for a rc.conf knob to check for existing cache, and skip the
>> rcorder part
>> +if checkyesno ${rc_cache_enable} ; then
>> + if [ -f ${rc_cache_file} ] ; then
>> + files=`cat ${rc_cache_file}`
>> + else
>> + files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null`
>> + echo "${files}" > ${rc_cache_file}
>> + fi
>> +else
>> + files=`rcorder ${skip} /etc/rc.d/* 2>/dev/null`
>> +fi
>>
>> for _rc_elem in ${files}; do
>> run_rc_script ${_rc_elem} ${_boot}
>
> I'm pretty sure you don't have access to the contents of /etc/rc.conf in
> this context. You would have to use another mechanism to control this
> feature. I'd be tempted to use the existance of a cache file (probably
> /etc/rcorder.cache since it can't be outside /) and simply require users
> to regenerate it externally when they upgrade (I'd probably add code to
> mergemaster to handle it like the various database files). Note that we
> may well break the ability to do this is easily in 7.0 if we end up
> supporting ordering of local scripts.
Would it be possible or in anyway not unreasonable to source rc.conf in
this file? Honestly I was working under the presumption that anytime
rc.subr was sourced that the knobs file was too, but possibly my bad. Not
that it matters, I can think of ways to work arround this, but I would
want to have a rc.d script later on to control the presence of the rcorder
cache file for the next boot, or something. I'd hate to use the existence
of files to control the functionality, where rc.conf knobs are ideal.
-Jon
>
> -- Brooks
>
> --
> Any statement of the form "X is the one, true Y" is FALSE.
> PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
>
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
