svn commit: r244198 - in head: etc/rc.d sbin/sysctl

[Garrett Cooper]

On Wed, Dec 19, 2012 at 12:14 PM, Chris Rees <utisoft at gmail.com> wrote:
>
> On 19 Dec 2012 19:37, "Garrett Cooper" <yanegomi at gmail.com> wrote:
>>
>> On Wed, Dec 19, 2012 at 7:37 AM, Ian Lepore
>> <freebsd at damnhippie.dyndns.org> wrote:
>>
>> ...
>>
>> > Instead of running sysctl a bunch of times, how about something
>> > conceptually similar to
>> >
>> >    cat /etc/sysctl.d/* /etc/sysctl.conf | sysctl -f -
>> >
>> > Along with this (untested) patch to make sysctl understand "-f -".
>> >
>> > Hmmm, is /dev/stdin available as early as sysctl.conf runs?  If not, the
>> > attached patch isn't going to work.
>>
>>     Why not just make sysctl understand multiple -f options? You're
>> probably going to run into more problems parsing from /dev/stdin and
>> it's going to obfuscate things a lot dealing with which file came
>> last, feeding back diagnostic info, etc.
>>     Please don't "linuxise" this tool.
>
> I seem to recall cpio being around a lot before Linux... Our sh also accepts
> piped scripts.  It's useful.

Yes, but it just compresses data and doesn't have to necessarily
backtrack in order to do so.

> ssh host cat file | sysctl -f -

I prefer:

ssh host cat file > foo
sysctl -f foo

... and my bikesheds navy blue.

Point is that Ian is potentially solving the problem incorrectly (his
concern is over I/O latency when booting up on slower platforms).
Unless he has measurements and tests to support doing this, it really
doesn't make sense to morph sysctl from the stripped down sh
"interpreter" that it is today into something that have to handle some
of the other error conditions and input permutations that hexdump/od
deals with (which his beforementioned patch doesn't do, neither did
the patch/commit that hrs/delphij posted) as real files are grossly
different from character devices and stdio file descriptors.

I would have less qualms if the support came directly from NetBSD as
there would have been some traction on it, but the problem is that the
proposal will a) make sysctl slower and bigger (I know more than a
handful of scripts that execute sysctl _a lot_, so the faster it is at
loading the image into memory and executing the better), and b) will
make sysctl diverge further from the other BSDs (which means less
testing, more code janitor work later on, have to deal with backport
issues, etc).

Traditional Unix philosophy is construction of simple commands with a
particular, well-defined purpose. Some of the suggestions made here
doing #file, etc are going in a very Linux centric direction by making
sysctl into a custom swiss army knife that does 20 different things
instead of [again] solving what the root issue is in Ian's case:
making his system boot faster.

Thanks,
-Garrett