On Sat, Jun 04, 2011 at 08:45:25PM +0200, Tom Gundersen wrote:
On Sat, Jun 4, 2011 at 8:22 PM, Dave Reisner <d@falconindy.com> wrote:
Upstream already supports this via the loglevel= parameter on the kernel cmdline, so we should support using this instead of our own homegrown solution.
Very nice. Is this in your public repo so I can pull directly?
i just created a for-tom branch to get around the conflict i mentioned. d
I will (probably) not accept any patches introducing new variables to rc.conf going forward. Removing/changing them is too much of a hassle.
Other things, I'd like to see go:
HARDWARECLOCK: the third line in /var/lib/hwclock/adjtime contains this information, and should be moved to /etc (following upstream), but discussion needed. The value is set by "hwclock --systohc --{utc,localtime}".
There's gotta be a reason that everyone puts the adjust file in /var/lib instead of /etc. I'm really not sure what that reason is, though.
TIMEZONE: /etc/localtime contains this information and is not kept properly in sync with rc.conf. Would need a nice cmdline tool to update /etc/localtime. USECOLOR: not important, but we should be able to detect if color is supported...
Even if you can support color, you might not necessarily want it.
UDEV_TIMEOUT: the standard value is tweaked from time to time by upstream, so they probably know better than us what is a good default. We'll get rid of it once it is supported in udev.conf (should be a simple upstream patch, which will be accepted as it is on their TODO). NETWORK_PERSIST: once we find a way to auto-detect if this is needed. This should be simple, but we would need someone with the relevant setup to test.
Very hard, if not impossible, to do with a high degree of accuracy. I think this one may need to stick around. Maybe there's a magical silver bullet I don't know about. Other distros maintain a list of network filesystem and tie that into their shutdown procedure to avoid killing the network.
USE{LVM,DMRAID,BTRFS}: once they are handled by udev (don't know how difficult that will be, a task for upstream)
Cheers,
Tom