On Thu, 21 Jun 2012 12:22:08 +0200 (CEST)
Wojciech Puchar <woj...@wojtek.tensor.gdynia.pl> wrote:
> Lets make a summary.
>
> What functionality would be good to have in FreeBSD that doesn't exist:
>
> 1) "runlevels" with arbitrary names. runlevel change would start and stop
> right services.
With a couple of additions:
- it should be easy to see which services are on at a given runlevel.
- it should be easy to see which runlevels a service is on at.
> 2) exploit startup parallelism.
>
>
> What we do not want to change:
>
> - file structure which is simple. one file in rc.d/ per service and one
> global config file (rc.conf)
> - anything else that would make things more complicated.
>
>
> As for
>
> 1) i propose in rc.conf an option to put "NO", "YES" (or ALL) or runlevel
> list for each service or runlevel exclusion list for service.
>
>
> examples:
>
> service1_enable="YES"
> service2_enable="NO"
> service3_enable="foolevel maintenance"
> service4_enable="YES -foolevel" (or ALL -funkyrunlevel)
Using two symbols to indicate negation - one to start, and then one on
each runlevel - is overkill. There's not a use case where you have a
keyword YES or ALL and then runlevels that you start. Personally, I'd
restrict YES/NO/ALL to being single symbols, and use "NOT runlevels"
to mean "All but these". A bare "NOT" should get the same treatment as
a YES/NO/ALL with text after it.
> name of default runlevel may be "full" or "multiuser"
>
> service 1 will always work, service 2 never, service 3 only at runlevels
> "foolevel" and "maintenance", service4 with any runlevel except
> "foolevel".
>
> still single rc.conf, not much bigger in practice.
But each line has become more complicated, going from a simple on/off
setting to a small language that can even have errors (like "foolevel
-barlevel"). This violates the second thing on your list of things we
don't want to change. Further, while you can easily tell what
runlevels a service is on at, you can't easily tell what services are
on at a given runlevel - that begs for a tool to be written.
If you instead violate the requirement that we stick with a single
rc.conf, the conf files can continue to have the same contents. For
instance, create rc.conf.d/<runlevel>. If rc.conf exists, we just
ignore the directory. Otherwise, use rc.conf/<runlevel>. Or maybe
rc.conf gets is a link to rc.conf/default.
The downside is that it adding a service now becomes harder - you have
to edit each runlevel script instead of just one. This also begs for a
tool to be written. Given the choice between having a file that wants
a tool for reading, or one that wants a tool for writing, I'll take
the latter.
> 2) no change in rc.d/* scripts and rc.conf, but change in scripts.
That's also true for my proposal.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
