El Sat, 17 Nov 2007 21:59:39 +0100 Eric MSP Veith <[EMAIL PROTECTED]> escribió:
> On Saturday 27 October 2007, Ismael Luceno <[EMAIL PROTECTED]>
> wrote:
> > Well, the problem here is that it's very expensive to stat/read a
> > lot of small files in contrast to read only one file once, and it
> > doesn't helps with compatibility...
>
> Yes, it's true that it will slow down initng more than reading one
> big file. However the file system solution just naturally provides us
> with a hierarchy. This is very useful, just imagine nic configuration
> (I remember the /etc/net project that accomplished a fairly complex
> configuration for a large number of nics).
> And, second, it just keeps syntax errors away.
>
> I experimented with some config file formats. What "won" was the
> block-like format we use in the ifiles, like
>
> nic eth0 = {
> config-style = static;
> ip-address = 192.168.2.4;
> ip-prefix = 24;
> }
>
> nic eth1 = {
> config-style = dhcp;
> }
>
Now that we're using shell scripts, is it worth implementing such
formats?, isn't easier to put that on the hands of the shell?.
>
> > A better solution IMO, is to have a static script to config-file
> > mapping [...]
>
> What do you mean by this? Sorry, I don't understand.
Well, I mean that each script should have a configuration file, and
only one, independently of the distribution.
>
> What also came to my mind was some sort of meta-configuration. For
> example with the net configuration, a little program could be used by
> the admin to set up the ip configuration, and then it just generates
> an ifile from it.
>
Please don't implement it, that's a lot more complicated, and doesn't
solves any of our current nor future problems.
My idea is:
Every configuration variable must be put in the environment. We could
eventually develop a configuration plugin to manage everything in a
dynamic way.
I have a simple idea to remove the barriers we have at the early boot
stages. We could require a /init/ directory, where we can mount a
tmpfs, and use a lot of clever things to manage the boot process in an
easier and clean way. That will enable to create boot logs directly,
for example, but of course will make initng depend on tmpfs (or
equivalents on other OS).
That way we could also export a lot of information about the system
status, so we could check things directly, without need for ngc. In
fact, i want to get rid of the current ngc completely, and replace it
with a front-end to manage these things in a user friendly way.
Initng could be a lot better at many things if we implement service_db
and process_db over files; for example, reloading could be much cleaner,
so it's something we should take seriously.
signature.asc
Description: PGP signature
-- _______________________________________________ Initng mailing list [email protected] http://jw.dyndns.org/mailman/listinfo/initng
