Date: Wed, 1 Jul 1998 22:40:39 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: fullermd@futuresouth.com (Matthew D. Fuller) Cc: mike@smith.net.au, jkh@time.cdrom.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Adding a new user interface to FreeBSD administration Message-ID: <199807012240.PAA24131@usr07.primenet.com> In-Reply-To: <19980630181153.08867@futuresouth.com> from "Matthew D. Fuller" at Jun 30, 98 06:11:53 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > linux(enabled) = YES
> > > > linux(doc) = { This variable controls whether linux emulation support
> > > > will be automatically loaded at startup. You can also do it manually
> > > > with the /usr/bin/linux command. }
> > > > linux(exec-command) = "linux > /dev/null 2>&1"
> > >
> > > OK, so what's wrong with a simple /etc/rc.conf script that looks
> > > something like:
> >
> > It doesn't scale.
>
> I don't see how.
> Unless there's a limit (that we're likely to reach) on how long a shell
> variable can be. I'm sure there is, but I'm not sure if it's low enough
> that we're likely to hit it on a bootup sequence.
It doesn't scale because it's a linearly exponential increase in
overhead for the programs that source it as they search linearly
through the name space for variables which might apply to them.
It's also insufficiently dynamic, insufficiently hierarchical, and
the interface is insufficiently abstact. The point of an abstract
interface is to hide complexity. This doesn't hide complexity of
greater than O(1).
> I mean, it's the same way Jordan was going with a 'registry', except
> thrown into a script. I can see it getting a little unwieldy at extreme
> sizes, but then again, there's only so much you're really going to be
> DOING on bootup.
It's not just for booting. Consider the case of wanting to restart
amd, for example. Your script would have to source all of rc.conf
(or whatever you called it).
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807012240.PAA24131>