Making powerd=YES default
Jean-Yves Migeon
Would it be acceptable to turn powerd on by default? Rationale follows:
My current save/restore code for Xen makes use of it. The way the Xen
API is designed does not permit sending back notifications to dom0 to
inform that suspension cannot be done, and this ends up with a xm(1)
command sleeping ~forever without the user's knowing why.
IMHO this is quite inconvenient from an admin's perspective, and the
only ways around are:
1 - to have powerd(8) enabled by default,
2 - let the domU start it (assuming he knows that he has to) before
firing suspend events. Assuming that the dom0 admin is not necessarily
the domU's admin, this can be problematic.
3 - completely circumvent powerd(8) by managing the event in kernel,
and let the pmf(9) threads perform the sleep for us.
IMHO, 1) looks like the best trade off. 3) feels awkward, because it's
a choice that says powerd(8) might not be necessary for suspension,
which is a departure from delegating power management to userland.
Opinions welcome. if no one objects, I'll go for 1) in a week or so :)
Cheers,
--
Jean-Yves Migeon
jeanyve...@free.fr
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Emmanuel Dreyfus
> Would it be acceptable to turn powerd on by default?
Since I always have to enable it, I would rather think it is a
good idea, but are there any drawbacks? Memmory footprint
on embedded ports comes to my mind, but do is stock rc.conf used
in such setup?
I also assume there are ports where powerd is of no benefit. Therefore
enabling it there would just consume memory for nothing, wouldn't it?
--
Emmanuel Dreyfus
ma...@netbsd.org
Marc Balmer
> Dear all,
>
> Would it be acceptable to turn powerd on by default? Rationale follows:
>
> My current save/restore code for Xen makes use of it. The way the Xen
> API is designed does not permit sending back notifications to dom0 to
> inform that suspension cannot be done, and this ends up with a xm(1)
> command sleeping ~forever without the user's knowing why.
>
> IMHO this is quite inconvenient from an admin's perspective, and the
> only ways around are:
> 1 - to have powerd(8) enabled by default,
> 2 - let the domU start it (assuming he knows that he has to) before
> firing suspend events. Assuming that the dom0 admin is not necessarily
> the domU's admin, this can be problematic.
> 3 - completely circumvent powerd(8) by managing the event in kernel, and
> let the pmf(9) threads perform the sleep for us.
>
> IMHO, 1) looks like the best trade off. 3) feels awkward, because it's a
> choice that says powerd(8) might not be necessary for suspension, which
> is a departure from delegating power management to userland.
>
> Opinions welcome. if no one objects, I'll go for 1) in a week or so :)
My opinion is: It should *not* be enabled by default, but rather during
system install time, i.e. in sysinst, towards the end of the
installation, the user should be asked a few questions:
- Do you want to run powerd by default?
- Do you want to run sshd by default?
- etc.
sysinst can then taylor /etc/rc.conf accordingly.
(The OpenBSD installer asks such questions during install, you might
want to check that one to see what I mean.)
Jean-Yves Migeon
> Since I always have to enable it, I would rather think it is a
> good idea, but are there any drawbacks?
Except for memory, I can't see any; the binary itself has a reasonable
size (it's actually 16k when dynamically linked, on my host). Note that
it requires proplib(3) and util(3), so that would count a grand total of
~150k.
> Memmory footprint
> on embedded ports comes to my mind, but do is stock rc.conf used
> in such setup?
Well, these days, most embedded systems do not have the same stringent
memory requirements as the ones of a toaster :)
But anyhow, you can still turn it off (or disable it), this will have a
minimal impact.
> I also assume there are ports where powerd is of no benefit.
> Therefore
> enabling it there would just consume memory for nothing, wouldn't it?
Of course, anything started but not used waists memory, that's
something you can't know in advance :)
Taking the stock etc/defaults/rc.conf:
[...]
inetd=YES inetd_flags="-l" # -l logs libwrap
syslogd=YES syslogd_flags="-s" # -s "secure" unix domain only
cron=YES
[...]
There are already some daemons marked as "YES" by default.
In case this raises too many objections, I can add a line in
etc.[i386,amd64]/Makefile to patch etc/rc.conf and add a local override.
People will have to be careful during updates with etcupdate/postinstall
though.
--
Jean-Yves Migeon
jeanyve...@free.fr
Adam Hoka
It's like: Do you install NetBSD on a machine not from the garbage?
powerd on i386/amd64 pretty much part of the hardware support
(although some of us would like to have less of its functionality in
userspace, eg possibility to use aps, without touching the disk)
> - Do you want to run sshd by default?
> - etc.
>
> sysinst can then taylor /etc/rc.conf accordingly.
>
> (The OpenBSD installer asks such questions during install, you might
> want to check that one to see what I mean.)
>
>
>
--
NetBSD - Simplicity is prerequisite for reliability
Matt Thomas
Not all arches support power management. Maybe there should be a sysctl which indicates whether the kernel support power management. /etc/rc.d/powerd could check this to see if starting powerd makes sense. How does powerd determine the power states that are supported?
Jean-Yves Migeon
> My opinion is: It should *not* be enabled by default, but rather
> during
> system install time, i.e. in sysinst, towards the end of the
> installation, the user should be asked a few questions:
>
> - Do you want to run powerd by default?
> - Do you want to run sshd by default?
> - etc.
>
> sysinst can then taylor /etc/rc.conf accordingly.
Last time I did an OpenBSD install from scratch, this was only about
enabling sshd.
> (The OpenBSD installer asks such questions during install, you might
> want to check that one to see what I mean.)
More levers, knobs, buttons :)
I can understand the question about sshd: the daemon serves a purpose
most people know about, and running such a service has an important
impact on the system (it's a possible remote access, like all network
daemons). powerd isn't really the same kind of daemon.
IMHO, it's a matter of reasonable defaults here. I bet most NetBSD
users (and even a fair amount of developers) won't be familiar with the
idea that "you need powerd(8) to run _before_ you can manage sleep
events under a Xen domU".
When we'll start having questions like "I tried an xm save but the
command froze afterwards, and domU is still executing, what am I doing
wrong?", it won't be that funny to answer them all. And I'd like to
avoid the route of "just do everything in kernel it's easier", or
"foobar allows doing this and that, if you are unsure say [Y] to the
question."
As said to Emmanuel, I have no problem enabling it on a per-arch basis
by patching etc.[i386,amd64]/Makefile.
--
Jean-Yves Migeon
jeanyve...@free.fr
Jean-Yves Migeon
> It's like: Do you install NetBSD on a machine not from the garbage?
> powerd on i386/amd64 pretty much part of the hardware support
> (although some of us would like to have less of its functionality in
> userspace, eg possibility to use aps, without touching the disk)
What do you mean by "without touching the disk"? Make powerd(8) a
daemon with RT priority and disabling swapping for it?
--
Jean-Yves Migeon
jeanyve...@free.fr
Paul Goyette
> Not all arches support power management. Maybe there should be a
> sysctl which indicates whether the kernel support power management.
> /etc/rc.d/powerd could check this to see if starting powerd makes
> sense. How does powerd determine the power states that are supported?
powerd invokes the scripts /etc/powerd/scripts/sensor_* and it is the
scripts' job to decide what to do.
-------------------------------------------------------------------------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-------------------------------------------------------------------------
Marc Balmer
Don't misunderstand my opinion as a "veto" (to which I would not be
entitled anyway), it was more of a spontaneous reaction to having one
more daemon being started by default.
That said, you are the expert in the area and if you find it's worth
doing it, that outweighs my opinion. ;)
Taylor R Campbell
From: Marc Balmer <mba...@NetBSD.org>
My opinion is: It should *not* be enabled by default, but rather during
system install time, i.e. in sysinst, towards the end of the
installation, the user should be asked a few questions:
- Do you want to run powerd by default?
- Do you want to run sshd by default?
- etc.
Please don't do this. Sysinst should ask fewer questions, not more
questions. We already have afterboot(8) for these. The only
questions sysinst should ask are those without whose answers the
system cannot boot.
Interactive questions in installers carry a tremendous burden: you
probably haven't thought about them until the moment the installer
asks them, you can't make progress or explore on your own without
answering them, and once you answer them -- or defer answering them,
if you can -- it's not clear what effects your answers had or how to
revisit the answers.
Jonathan A. Kollasch
>
> Would it be acceptable to turn powerd on by default? Rationale follows:
>
> My current save/restore code for Xen makes use of it. The way the
> Xen API is designed does not permit sending back notifications to
> dom0 to inform that suspension cannot be done, and this ends up with
> a xm(1) command sleeping ~forever without the user's knowing why.
>
> IMHO this is quite inconvenient from an admin's perspective, and the
> only ways around are:
> 1 - to have powerd(8) enabled by default,
> 2 - let the domU start it (assuming he knows that he has to) before
> firing suspend events. Assuming that the dom0 admin is not
> necessarily the domU's admin, this can be problematic.
> 3 - completely circumvent powerd(8) by managing the event in kernel,
> and let the pmf(9) threads perform the sleep for us.
>
> IMHO, 1) looks like the best trade off. 3) feels awkward, because
> it's a choice that says powerd(8) might not be necessary for
> suspension, which is a departure from delegating power management to
> userland.
>
> Opinions welcome. if no one objects, I'll go for 1) in a week or so :)
I'd do it like we handle wscons=YES on x86. That is, have sysinst do it
without asking. Sysinst will at least know what port it's installing,
and if it is probably appropriate to enable it.
Jonathan Kollasch
Mouse
>> Therefore enabling it there would just consume memory for nothing,
>> wouldn't it?
> something you can't know in advance :)
On some ports you can; some ports don't support any hardware on which
powerd is ever of any use. (I think dreamcast qualifies, for exmaple.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
jean-Yves Migeon
>>> I also assume there are ports where powerd is of no benefit.
>>> Therefore enabling it there would just consume memory for nothing,
>>> wouldn't it?
>> Of course, anything started but not used waists memory, that's
>> something you can't know in advance :)
>
> On some ports you can; some ports don't support any hardware on which
> powerd is ever of any use. (I think dreamcast qualifies, for
> exmaple.)
In that case, we can use power management backends. Change is minimal
to powerd(8) to tell it to exit when there is none (see the
POWER_IOC_GET_TYPE ioctl).
--
Jean-Yves Migeon
j...@NetBSD.org
Jean-Yves Migeon
>>> My opinion is: It should *not* be enabled by default, but rather
>>> during
>>> system install time, i.e. in sysinst, towards the end of the
>>> installation, the user should be asked a few questions:
>>>
>>> - Do you want to run powerd by default?
>>
>> It's like: Do you install NetBSD on a machine not from the garbage?
>> powerd on i386/amd64 pretty much part of the hardware support
>> (although some of us would like to have less of its functionality in
>> userspace, eg possibility to use aps, without touching the disk)
>
> Not all arches support power management. Maybe there should be a
> sysctl which indicates whether the kernel support power management.
> /etc/rc.d/powerd could check this to see if starting powerd makes
> sense. How does powerd determine the power states that are
> supported?
When starting, it queries for power backends. If there are none, it
bails out.
Note that power management backends are currently "not supported" (e.g.
the interfaces in kernel are present, but nothing uses them at the
moment)
--
Jean-Yves Migeon
jeanyve...@free.fr
David Brownlee
> Am 25.07.11 14:38, schrieb Jean-Yves Migeon:
>> Dear all,
>>
>> Would it be acceptable to turn powerd on by default?
>
> My opinion is: It should *not* be enabled by default, but rather during
> system install time, i.e. in sysinst, towards the end of the
> installation, the user should be asked a few questions:
>
> - Do you want to run powerd by default?
> - Do you want to run sshd by default?
> - etc.
>
> sysinst can then taylor /etc/rc.conf accordingly.
>
> (The OpenBSD installer asks such questions during install, you might
> want to check that one to see what I mean.)
It might almost be worth having a screen with a list of all the common
settings and let the user toggle them on and off (or set values),
similar to which sets are installed. That way someone can just accept
the defaults without having to answer half a dozen questions, plus
someone who wants to set specific items doesn't have to risk the
y,y,y,y, damn, missed the one I wanted to set
eg:
A) root shell /bin/ksh
B) Enable ssh YES
C) Enable powerd YES
D) ...
Jean-Yves Migeon
> On 25 July 2011 14:52, Marc Balmer <mba...@netbsd.org> wrote:
>> (The OpenBSD installer asks such questions during install, you might
>> want to check that one to see what I mean.)
>
> It might almost be worth having a screen with a list of all the
> common
> settings and let the user toggle them on and off (or set values),
> similar to which sets are installed. That way someone can just accept
> the defaults without having to answer half a dozen questions, plus
> someone who wants to set specific items doesn't have to risk the
> y,y,y,y, damn, missed the one I wanted to set
>
> eg:
>
> A) root shell /bin/ksh
> B) Enable ssh YES
> C) Enable powerd YES
> D) ...
A bit out of scope of my original question, he?
sysinst will need a major overhaul anyway, as there are many features
people would you like to see in it (automated installs, configuration
files, third parties pkg installs, etc.). And this fits in.
--
Jean-Yves Migeon
jeanyve...@free.fr
Emmanuel Dreyfus
> As said to Emmanuel, I have no problem enabling it on a per-arch
> basis by patching etc.[i386,amd64]/Makefile.
I think the sysctl telling that power management is avaiable, and
having powerd start or not depending on it, is a good idea: the
syscl could be usefull for other purposes.
--
Emmanuel Dreyfus
ma...@netbsd.org
Jukka Ruohonen
> command froze afterwards, and domU is still executing, what am I doing
> wrong?", it won't be that funny to answer them all. And I'd like to
> avoid the route of "just do everything in kernel it's easier", or
> "foobar allows doing this and that, if you are unsure say [Y] to the
> question."
Indeed. People have already had to answer comparable questions for years.
And as we have discussed previously, it is presumably a bad design choice to
even consider the option of "doing everything in the kernel", given the
inherited complexity of power management and "platform specific events".
On Mon, Jul 25, 2011 at 06:11:39PM +0000, Emmanuel Dreyfus wrote:
> I think the sysctl telling that power management is avaiable, and
> having powerd start or not depending on it, is a good idea: the
> syscl could be usefull for other purposes.
Like Jean-Yves pointed out, powerd(8) is not strictly related to "power
management" but rather to generic hardware support. I don't see any reason
for more magic, undocumented, buttons.
On Mon, Jul 25, 2011 at 03:34:19PM +0000, Jonathan A. Kollasch wrote:
> I'd do it like we handle wscons=YES on x86. That is, have sysinst do it
> without asking. Sysinst will at least know what port it's installing,
> and if it is probably appropriate to enable it.
I think this might be a reasonable compromise.
- Jukka.
Jean-Yves Migeon
> On Mon, Jul 25, 2011 at 03:12:40PM +0100, Jean-Yves Migeon wrote:
>> basis by patching etc.[i386,amd64]/Makefile.
>
> having powerd start or not depending on it, is a good idea: the
> syscl could be usefull for other purposes.
In that case there's already some logic available in powerd(8). It's
trivial to make it exit(2) in situations where it doesn't find a power
management backend.
That's a bit different from the current code where it checks first that
/etc/powerd/scripts/<power_type> is present, then falls back to
/etc/powerd/scripts.
http://nxr.netbsd.org/xref/src/usr.sbin/powerd/powerd.c#141
http://nxr.netbsd.org/source/xref/src/sys/dev/sysmon/sysmon_power.c#743
Exposing the power management backend as a read-only sysctl is also an
option.
IMHO, powerd(8) shall exit unless there is code that explicitly
registers a backend. It has no real meaning (to me, at least) to handle
power events where there is nothing expecting it to be so.
There, /etc/powerd/scripts would rather be:
/etc/powerd/scripts/default/*
/etc/powerd/scripts/acpi/*
/etc/powerd/scripts/xen/*
/etc/powerd/scripts/<power_type>/*
[...]
Or even move away "scripts" entirely. Nothing specifies that these
should be scripts.
Martin Husemann
> There, /etc/powerd/scripts would rather be:
>
> /etc/powerd/scripts/default/*
> /etc/powerd/scripts/acpi/*
> /etc/powerd/scripts/xen/*
> /etc/powerd/scripts/<power_type>/*
> [...]
Unless you plan to share /etc/powerd/scripts between different machines, I
don't see what such subdirectories would buy you.
Martin
Jean-Yves Migeon
> On Mon, Jul 25, 2011 at 09:01:47PM +0200, Jean-Yves Migeon wrote:
>> There, /etc/powerd/scripts would rather be:
>>
>> /etc/powerd/scripts/default/*
>> /etc/powerd/scripts/acpi/*
>> /etc/powerd/scripts/xen/*
>> /etc/powerd/scripts/<power_type>/*
>> [...]
>
> Unless you plan to share /etc/powerd/scripts between different machines, I
> don't see what such subdirectories would buy you.
I didn't chose this; it's already hardcoded in powerd(8).
http://nxr.netbsd.org/xref/src/usr.sbin/powerd/powerd.c#146
Jukka Ruohonen
> registers a backend. It has no real meaning (to me, at least) to handle
> power events where there is nothing expecting it to be so.
>
> There, /etc/powerd/scripts would rather be:
>
> /etc/powerd/scripts/default/*
> /etc/powerd/scripts/acpi/*
> /etc/powerd/scripts/xen/*
> /etc/powerd/scripts/<power_type>/*
> [...]
Be careful with the above layout though. There is a lot of duplication (e.g.
already with x86 there would be ../scripts/acpi vs. ../scripts/apm vs.
../scripts/default). For instance, Xen might want to use some scripts from
../scripts/acpi and some from ../scripts/default.
But supposedly majority of the events are quite independent from the
machine and the power-type.
A long-term solution is to use more machine-independent APIs in the kernel;
perhaps more than anything else, both the above layout and the current
powerd(8) scripts are symptoms from not doing so.
- Jukka.
Marc Balmer
> On Mon, Jul 25, 2011 at 03:12:40PM +0100, Jean-Yves Migeon wrote:
>> basis by patching etc.[i386,amd64]/Makefile.
>
> having powerd start or not depending on it, is a good idea: the
> syscl could be usefull for other purposes.
Yes, indeed, I like this idea. That is way smarter than having sysinst
asking for it. So yes, start powerd by default and have it exit if it
finds out it can operate anyways.
Jukka Ruohonen
> Unless you plan to share /etc/powerd/scripts between different machines, I
> don't see what such subdirectories would buy you.
To further clarify this a little: IMO the scripts should be shared by
machines. But this implies consistent MI interfaces in the kernel.
Thus, the current hack is to either use the subdirectories or resort to
things like this (from scripts/sleep_button):
if /sbin/sysctl machdep.sleep_state >/dev/null 2>&1; then
/sbin/sysctl -w machdep.sleep_state=3
else
sleep 1
if /etc/rc.d/apmd status >/dev/null ; then
/usr/sbin/apm -z
else
/usr/sbin/apm -d -z
fi
# ... waking up
sleep 1
fi
Obviously, both approaches leave a lot to be desired.
- Jukka.
Jean-Yves Migeon
> On Mon, Jul 25, 2011 at 09:17:03PM +0200, Martin Husemann wrote:
>> don't see what such subdirectories would buy you.
>
> machines. But this implies consistent MI interfaces in the kernel.
>
> Thus, the current hack is to either use the subdirectories or resort to
> things like this (from scripts/sleep_button):
>
> Obviously, both approaches leave a lot to be desired.
Polishing power management framework (or even powerd(8)) is a really big
project in itself. It also has to offer interfaces for programming, like
time of wakeup, suspend maybe, and even policy (like power control:
powersaving or performance, etc.). This needs some thinking and trying,
before having something that we feel comfortable with.
IMHO, it should even be renamed from "powerd" to "eventd", as it will
probably manage more that just power (like aps(4)).
So let me summarize a bit, so we can move further; do everyone agree if I:
- patch powerd(8) so that it checks for power_type, and if none is
provided, log and exit
=> that means that all ports/arches that want to see powerd(8) enabled
and resident should now register a backend (nominal case).
=> in case some want to execute powerd(8) regardless of a backend
presence, add a flag for that (maybe -f?), and let those that want it
add it to rc.conf.
- set powerd=YES in etc/defaults/rc.conf
Please raise your voice if you have concerns.
Paul Goyette
least, it can receive and process temp-sensor alarms, intrusion
indicators, etc.) so it probably should not exit. If you exit, then
there's no way for user-land to process events from those other sensor
types...
On Tue, 26 Jul 2011, Jean-Yves Migeon wrote:
> On 25.07.2011 21:40, Jukka Ruohonen wrote:
>> On Mon, Jul 25, 2011 at 09:17:03PM +0200, Martin Husemann wrote:
>>> Unless you plan to share /etc/powerd/scripts between different machines, I
>>> don't see what such subdirectories would buy you.
>>
>> To further clarify this a little: IMO the scripts should be shared by
>> machines. But this implies consistent MI interfaces in the kernel.
>>
>> Thus, the current hack is to either use the subdirectories or resort to
>> things like this (from scripts/sleep_button):
>> [snip]
>>
>> Obviously, both approaches leave a lot to be desired.
>
> Polishing power management framework (or even powerd(8)) is a really big
> project in itself. It also has to offer interfaces for programming, like
> time of wakeup, suspend maybe, and even policy (like power control:
> powersaving or performance, etc.). This needs some thinking and trying,
> before having something that we feel comfortable with.
>
> IMHO, it should even be renamed from "powerd" to "eventd", as it will
> probably manage more that just power (like aps(4)).
>
> So let me summarize a bit, so we can move further; do everyone agree if I:
> - patch powerd(8) so that it checks for power_type, and if none is
> provided, log and exit
>
> => that means that all ports/arches that want to see powerd(8) enabled
> and resident should now register a backend (nominal case).
>
> => in case some want to execute powerd(8) regardless of a backend
> presence, add a flag for that (maybe -f?), and let those that want it
> add it to rc.conf.
>
> - set powerd=YES in etc/defaults/rc.conf
>
> Please raise your voice if you have concerns.
>
> --
> Jean-Yves Migeon
> jeanyve...@free.fr
>
> !DSPAM:4e2deae32356640612403!
>
>
>
-------------------------------------------------------------------------
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-------------------------------------------------------------------------
--
Jukka Ruohonen
> IMHO, it should even be renamed from "powerd" to "eventd", as it will
> probably manage more that just power (like aps(4)).
As Paul pointed out, it already does. The MI sysmon_envsys(9) uses powerd(8)
to deliver the sensor-events to userland. All of the scripts/sensor_* are
believed to be machine-independent and already used by several architectures
indirectly via the numerous MI drivers. Making the daemon to exit based on
the deceptive concept of "power backend" will break stuff.
I would either enable it for all architectures or do as J. Kollasch suggested.
Though I don't see how such a small daemon would do any harm even on memory-
constrained systems (you can still turn it off by powerd=OFF in rc.conf(5) in
your embedded projects).
- Jukka.
Marc Balmer
> Since powerd already deals with things other than power (at the very
> least, it can receive and process temp-sensor alarms, intrusion
> indicators, etc.) so it probably should not exit. If you exit, then
> there's no way for user-land to process events from those other sensor
> types...
Could these other event sources be identified somehow, so that powerd
(or eventd...) only exists if there is really nothing it can do?
>
>
> On Tue, 26 Jul 2011, Jean-Yves Migeon wrote:
>
>> !DSPAM:4e2deae32356640612403!
>>
>>
>>
>
> -------------------------------------------------------------------------
> | Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
> | Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com |
> | Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
> | Kernel Developer | | pgoyette at netbsd.org |
> -------------------------------------------------------------------------
Hauke Fath
>I would either enable it for all architectures or do as J. Kollasch suggested.
Well, there is not much point for architectures which have neither power
management, nor sensors. Most of m68k land will fall into that category. So
I'd prefer to see a machine-dependent setting.
hauke
--
"It's never straight up and down" (DEVO)
Adam Hoka
Jukka Ruohonen <jruo...@iki.fi> wrote:
> On Tue, Jul 26, 2011 at 12:14:39AM +0200, Jean-Yves Migeon wrote:
> > IMHO, it should even be renamed from "powerd" to "eventd", as it will
> > probably manage more that just power (like aps(4)).
>
> As Paul pointed out, it already does. The MI sysmon_envsys(9) uses powerd(8)
> to deliver the sensor-events to userland. All of the scripts/sensor_* are
> believed to be machine-independent and already used by several architectures
> indirectly via the numerous MI drivers. Making the daemon to exit based on
> the deceptive concept of "power backend" will break stuff.
>
> I would either enable it for all architectures or do as J. Kollasch suggested.
> Though I don't see how such a small daemon would do any harm even on memory-
> constrained systems (you can still turn it off by powerd=OFF in rc.conf(5) in
> your embedded projects).
>
> - Jukka.
who uses sysinst in an embedded project anyway? :)
--
NetBSD - Simplicity is prerequisite for reliability
Martin Husemann
> and resident should now register a backend (nominal case).
What does qualify as a backend? For example some sparc64 (U5 and U10)
can generate a sysmon_pswitch event when the front panel switch has
been pressed. This makes powerd do a gracefull shutdown. But there are
no otherwise relevant power management features present in the
hardware.
Martin
Martin Husemann
> who uses sysinst in an embedded project anyway? :)
Indeed.
All power management framework/powerd polishing aside, my vote for the
issue at hand is: enable it arch dependend in sysinst (like wscons). If
someone does not want it, they can change powerd=YES to powerd=NO in
/etc/rc.conf. I don't realy care for the default if there is no powerd=
line, but would leave that as NO.
Martin
Jean-Yves Migeon
> On Tue, Jul 26, 2011 at 12:14:39AM +0200, Jean-Yves Migeon wrote:
>> and resident should now register a backend (nominal case).
>
> can generate a sysmon_pswitch event when the front panel switch has
> been pressed. This makes powerd do a gracefull shutdown. But there are
> no otherwise relevant power management features present in the
> hardware.
IMHO, anything that expect powerd(8) to react to an event is a potential
power backend, even when the script is a NOP. In this case, sparc64
should register one (even a trivial name, like "sparc64").
powerd(8) isn't started in the default config, unless you configure it
explicitly. As such, it's not really used expect by a minority that
knows about it.
Jean-Yves Migeon
> Am 26.07.11 00:44, schrieb Paul Goyette:
>> Since powerd already deals with things other than power (at the very
>> least, it can receive and process temp-sensor alarms, intrusion
>> indicators, etc.) so it probably should not exit. If you exit, then
>> there's no way for user-land to process events from those other sensor
>> types...
>
> Could these other event sources be identified somehow, so that powerd
> (or eventd...) only exists if there is really nothing it can do?
Hmmm, depends: you can discriminate between events (and even their
content depending on the returned property list), but I am not sure if
you can enumerate them; IMHO, you cannot expect powerd(8) to react to
any kind of event unless you have some trigger already coded in kernel
for that (sysmon).
Currently, pswitch events are stateless: anyone can post one without
having the need to register it first; there's sysmon_pswitch_register()
(and unregister()), but ATM they are a NOP, and just return 0.
I can change the semantic of these operations and force them to
reference a power backend. In that case, that will force all sysmon
callers to:
- first register a power backend
- then register different sort of events (like pswitch).
Last time I had a look, I collided with the pmf_generic_event_t from
pmf(9), as they somehow duplicate this logic. When I asked which one I
should go for, there wasn't any clear direction given. Now I'd like to
finalize my save/restore work, and this is one of the last steps before
the merge.
Jean-Yves Migeon
> On Tue, Jul 26, 2011 at 12:14:39AM +0200, Jean-Yves Migeon wrote:
>> IMHO, it should even be renamed from "powerd" to "eventd", as it will
>> probably manage more that just power (like aps(4)).
>
> As Paul pointed out, it already does. The MI sysmon_envsys(9) uses powerd(8)
> to deliver the sensor-events to userland. All of the scripts/sensor_* are
> believed to be machine-independent and already used by several architectures
> indirectly via the numerous MI drivers. Making the daemon to exit based on
> the deceptive concept of "power backend" will break stuff.
I disagree there; the sysmon API already defines register functions for
events; you are supposed to register them first before posting them to
powerd.
Granted, the current registering operation is a NOP; but I think these
functions were introduced for one good reason, and here it is: if you
don't have any sort of event registered when powerd(8) starts, you
shouldn't expect it to handle some in a "stateless" manner later.
--
Jean-Yves Migeon
jeanyve...@free.fr
Jukka Ruohonen
Making a mountain out of a mole hill, but nevertheless...
See, also sysmon_envsys(9) uses this internally. If you want to do the
dubious and error-prone task of enumerating all powerd(8) users, you have to
go through all kernel configuration files on all architectures and all (MD
or MI) device drivers or other components that may use either sysmon_envsys(9)
or sysmon_pswitch(9). Then you have to maintain it.
I would say that the kernel does not need this kind of useless cruft.
Rather, we should make good default choices even if there is m68k.
> Granted, the current registering operation is a NOP; but I think these
> functions were introduced for one good reason, and here it is: if you
> don't have any sort of event registered when powerd(8) starts, you
> shouldn't expect it to handle some in a "stateless" manner later.
I think the actual reason is: sysmon(4) was never really finished.
> I can change the semantic of these operations and force them to
> reference a power backend. In that case, that will force all sysmon
> callers to:
> - first register a power backend
> - then register different sort of events (like pswitch).
Please don't.
Jean-Yves Migeon
> On Tue, Jul 26, 2011 at 09:37:30PM +0200, Jean-Yves Migeon wrote:
>
> Making a mountain out of a mole hill, but nevertheless...
>
> See, also sysmon_envsys(9) uses this internally. If you want to do the
> dubious and error-prone task of enumerating all powerd(8) users, you have to
> go through all kernel configuration files on all architectures and all (MD
> or MI) device drivers or other components that may use either sysmon_envsys(9)
> or sysmon_pswitch(9). Then you have to maintain it.
>
> I would say that the kernel does not need this kind of useless cruft.
> Rather, we should make good default choices even if there is m68k.
>
>> functions were introduced for one good reason, and here it is: if you
>> don't have any sort of event registered when powerd(8) starts, you
>> shouldn't expect it to handle some in a "stateless" manner later.
>
>
>> I can change the semantic of these operations and force them to
>> reference a power backend. In that case, that will force all sysmon
>> callers to:
>> - first register a power backend
>> - then register different sort of events (like pswitch).
>
> Please don't.
Then this leaves the sysinst route.
I can foretell a good amount of questions for NetBSD-6 and up, where
people upgrading straight from already installed systems will come in
and ask why xm/xl is dead frozen in dom0 for a save (because powerd(8)
wasn't started beforehand and only newly installed systems will have it
enabled by default).
Note that once you issue a save operation, you cannot really undo it at
this step. The domain will be marked in a "migrating-<dom-name>" state.
So if you issue a save and forgot to start powerd(8), you will have to
run powerd/scripts/sleep_button manually in domU.
--
Jean-Yves Migeon
jeanyve...@free.fr
Martin Husemann
> Then this leaves the sysinst route.
Let's define a set of archs where we enable it by default in
sysinst (by writing powerd=YES to rc.conf).
Let's also add a check to usr.sbin/postinstall to nag if on one of those
args there is no explicit powerd= line in rc.conf and suggest to the user
to enable it (or make the nagging stop by an explicit powerd=NO line).
Martin
Julio Merino
> On Tue, Jul 26, 2011 at 10:43:27PM +0200, Jean-Yves Migeon wrote:
>
> sysinst (by writing powerd=YES to rc.conf).
>
> Let's also add a check to usr.sbin/postinstall to nag if on one of those
> args there is no explicit powerd= line in rc.conf and suggest to the user
> to enable it (or make the nagging stop by an explicit powerd=NO line).
Why then not hardcode all this logic in the powerd rc.d script so that
this is all transparent?
Martin Husemann
> Why then not hardcode all this logic in the powerd rc.d script so that
> this is all transparent?
Because it hides the magic in a script that the user should not have to
touch? But maybe I misunderstand what you are proposing.
Martin
Julio Merino
> On Wed, Jul 27, 2011 at 10:27:17AM -0400, Julio Merino wrote:
>> Why then not hardcode all this logic in the powerd rc.d script so that
>> this is all transparent?
>
> Because it hides the magic in a script that the user should not have to
> touch? But maybe I misunderstand what you are proposing.
What I meant is that, if sysinst is going to decide if powerd should
start or not based on the architecture, I don't see why the powerd rc.d
script could not decide this by itself. And by doing so, you'd avoid
the need for the postinstall check.
Martin Husemann
> What I meant is that, if sysinst is going to decide if powerd should
> start or not based on the architecture, I don't see why the powerd rc.d
> script could not decide this by itself. And by doing so, you'd avoid
> the need for the postinstall check.
The difference is: the user can easily change the value sysinst put into
rc.conf - but we can not recommend the user to hack rc.d/powerd.
Martin
Jean-Yves Migeon
> On 7/27/11 10:38 AM, Martin Husemann wrote:
>>> Why then not hardcode all this logic in the powerd rc.d script so that
>>> this is all transparent?
>>
>> Because it hides the magic in a script that the user should not have to
>> touch? But maybe I misunderstand what you are proposing.
>
> start or not based on the architecture, I don't see why the powerd rc.d
> script could not decide this by itself. And by doing so, you'd avoid
> the need for the postinstall check.
IMHO, users would expect rc.d scripts to be self-consistent, that is:
their behavior should not be dictated by the architecture (or any
particular system feature). However, rc.conf (and defaults/) should be,
as they are configuration-related files. But there's no /etc/powerd.conf
file :o
--
Jean-Yves Migeon
jeanyve...@free.fr
Jukka Ruohonen
> But there's no /etc/powerd.conf file :o
Yes. There is a lot to do. I pinpoint to the following discussion where it
was already concluded that rc.conf(5)-like configuration file for powerd(8)
is a good idea;
http://mail-index.netbsd.org/tech-userlevel/2011/05/06/msg005009.html
Jean-Yves Migeon
> On Wed, Jul 27, 2011 at 11:18:01AM -0400, Julio Merino wrote:
>> What I meant is that, if sysinst is going to decide if powerd should
>> start or not based on the architecture, I don't see why the powerd rc.d
>> script could not decide this by itself. And by doing so, you'd avoid
>> the need for the postinstall check.
>
> The difference is: the user can easily change the value sysinst put into
> rc.conf - but we can not recommend the user to hack rc.d/powerd.
Sooo... let's make another attempt, until I finally get a solution
acceptable by everyone (or at least the ones who raise their voice).
Instead of hiding this step in sysinst, the attached patch uses the
Makefiles living under src/etc/. It mimics the MD disktab logic: takes
the default rc.conf that lives under etc/ or the one under etc.MACHINE/
(when it exists).
Obviously, the MD rc.conf have wscons/powerd=YES inside.
Why I am suggesting this: as rc.conf gets patched directly in the MD
sets, it will be managed by etcupdate(8). So anyone who is updating is
seeing the wscons/powerd=YES lines now, instead of just those that use
sysinst-install.
Opinions?
--
Jean-Yves Migeon
jeanyve...@free.fr
Martin Husemann
> Why I am suggesting this: as rc.conf gets patched directly in the MD
> sets, it will be managed by etcupdate(8). So anyone who is updating is
> seeing the wscons/powerd=YES lines now, instead of just those that use
> sysinst-install.
Not everyone uses etcupdate.
Will an official update via sysinst now have the correct values in rc.conf?
Martin
Jean-Yves Migeon
> On Sun, Jul 31, 2011 at 08:15:56PM +0200, Jean-Yves Migeon wrote:
>> sets, it will be managed by etcupdate(8). So anyone who is updating is
>> seeing the wscons/powerd=YES lines now, instead of just those that use
>> sysinst-install.
>
> Will an official update via sysinst now have the correct values in rc.conf?
Good point; nope. That's something you can only do via postinstall(8).
From what I have seen so far, there are multiple situations to check:
1 - install from scratch. Handled either via add_rc_conf(...) (available
only via sysinst), or attached patch (which adds the option directly in
i386/amd64 etc.tgz set)
2 - update using sets + postinstall + etcupdate. Handled only via
postinstall or etcupdate, obviously.
3 - update via sysinst. Only handled via postinstall.
4 - using build.sh install=<target>, and configure <target>/etc/ afterwards.
5 - fully manual. At operator's own risk.
IMHO, the only way to cover most of the possibilities is to add the
powerd=YES line directly inside etc.tgz set, which will happen at
"build.sh distribution" time. That will cover most (all?) install methods.
For upgrade, I patched postinstall(8). It won't fix the issue by itself,
but will raise a warning in case it's not enabled.
Thoughts?
--
Jean-Yves Migeon
jeanyve...@free.fr
Jean-Yves Migeon
> On Mon, Aug 01, 2011 at 01:02:16AM +0200, Jean-Yves Migeon wrote:
>> + # Starting with NetBSD-6.0, powerd(8) has to be enabled under
>> + # i386/amd64 to support Xen domU save/restore.
>> + if [ "$MACHINE" = "i386" ] || [ "$MACHINE" = "amd64" ]; then
>> + if ! rcvar_is_enabled "powerd"; then
>> + msg \
>> + "powerd(8) is not enabled in rc.conf(5)${notfixed}: use powerd=YES"
>> + failed=$(( ${failed} + 1 ))
>> + fi
>> + fi
>
> Can we please use rcconf_is_set (or a variant of that) instead of
> rcvar_is_enabled? There might be legitimate reasons to force it to NO
> by the user and if they do so, we should not nag about it on every later
> update.
Well, it is set to "NO" by default. So if the entry is missing from
/etc/rc.conf, it won't be started. There's no point in adding
"powerd=NO" to rc.conf by the user.
What do you want to achieve? Have a "rcvar_is_set" that tests presence
of the variable in rc.conf, and bails out if it does?
And in case it doesn't find a powerd=<whatever> line, add powerd=YES to
the file directly, or keep the "requires a manual fix"?
--
Jean-Yves Migeon
jeanyve...@free.fr
Martin Husemann
> What do you want to achieve?
I want a way to not run powerd (even on i386) and still make postinstall
quiet.
Jean-Yves Migeon
> On Mon, Aug 01, 2011 at 12:54:24PM +0200, Jean-Yves Migeon wrote:
>> What do you want to achieve?
>
> I want a way to not run powerd (even on i386) and still make postinstall
> quiet.
The sentence contradicts itself: postinstall cannot guess what the user
wants, it can only suggest defaults. Adding powerd checks to the
disabled items list nullifies the chance to fix the requirement on upgrade.
BTW, there's no way for a user to specify that a service shall remain
disabled within rc(8) upon update. It's not rc(8) concern anyway.
There are multiple ways to fix my requirement. Sadly, this needs to add
MD hooks somewhere: rc.d/powerd, etcupdate/postinstall, rc.local,
whatever. Or even a pure-kernel solution, thereby circumventing all the
powerd/sysmon code (if you want to go the Linux way).
While rc.conf(5) is parsed as a shell script, it's somewhat
controversial to add conditions within (remember the discussion about
Turing complete configuration files).
I don't really care what solution gets accepted in the end, I need one
that can command kernel to suspend, and currently, powerd is the only
one, as Xen power events are managed via sysmon. Note that suspend isn't
idempotent under Xen, and can only be submitted once. If powerd(8) isn't
there to capture the event, it's lost forever.
So now, I suggest you propose an alternative, so that we can make some
progress. Thanks.
--
Jean-Yves Migeon
jeanyve...@free.fr
Martin Husemann
> progress. Thanks.
But I did! If postinstall just checks wether there is a powerd= line in
rc.conf (even if it would not be required functionally), everything is
fine. You could slightly tweak the failure message to hint at this
possibility, but I wouldn't mind to just keep it as in your suggested
patch.
Martin
Jean-Yves Migeon
>> So now, I suggest you propose an alternative, so that we can make some
>> progress. Thanks.
>
> rc.conf (even if it would not be required functionally), everything is
> fine. You could slightly tweak the failure message to hint at this
> possibility, but I wouldn't mind to just keep it as in your suggested
> patch.
It isn't easy: by design, rc.conf executes /etc/defaults/rc.conf by default:
# Load the defaults in from /etc/defaults/rc.conf (if it's readable).
# These can be overridden below.
#
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
fi
So I can't easily know where the powerd=NO line comes from
(/etc/defaults/rc.conf or /etc/rc.conf).
Grepping for it is not really deterministic; anyone is free to add shell
semantic, and hide the value of "powerd" behind shell commands.
Hacking around this without patching /etc/rc.conf (two steps needed, one
to patch, and another one to test value) requires a modification from
/etc/defaults/rc.conf:
Index: etc/defaults/rc.conf
===================================================================
RCS file: /cvsroot/src/etc/defaults/rc.conf,v
retrieving revision 1.113
diff -u -p -u -p -r1.113 rc.conf
--- etc/defaults/rc.conf 27 May 2011 09:28:42 -0000 1.113
+++ etc/defaults/rc.conf 1 Aug 2011 15:20:58 -0000
@@ -26,6 +26,12 @@
#
#rc_fast_and_loose=YES
+# If RC_SKIP_DEFAULTS is set, ignore the rest of the file. Used to
distinguish
+# /etc/defaults/rc.conf and /etc/rc.conf contents.
+if [ -z "${RC_SKIP_DEFAULTS}" ]; then
+ return
+fi
+
# If rc_silent is true then /etc/rc will suppress most output to
# the console. The default is taken from the AB_SILENT flag passed
# from the boot loader to the kernel in the boothowto(9) variable.
Obviously, for the first time, this has to be applied _before_ testing
the rcvar value. Which means that upon postinstall, "check" => "fix" =>
"check" won't return deterministic results upon first update.
We might as well provide a MD /etc/defaults/rc.conf file, things are
becoming ugly there...
Martin Husemann
> Obviously, for the first time, this has to be applied _before_ testing
> the rcvar value. Which means that upon postinstall, "check" => "fix" =>
> "check" won't return deterministic results upon first update.
See the bluetooth changed Iain did a few days ago, which had just the
same issue.
Martin
Jean-Yves Migeon
> On Mon, Aug 01, 2011 at 05:24:23PM +0200, Jean-Yves Migeon wrote:
>> the rcvar value. Which means that upon postinstall, "check" => "fix" =>
>> "check" won't return deterministic results upon first update.
>
> same issue.
We're not in the same situation: bluetooth is about migrating from the
old rcvar variables to the "bluetooth" one. Mine is about keeping the
same variable, but enable it on a per-arch basis.
In addition (from you): keep the same setting in case the user
explicitly added a powerd configuration to /etc/rc.conf, and stay quiet
on this issue.
Quite frankly, I am more and more convinced that an additional
/etc/defaults/rc.md.conf is the right fix then. This one could be
included from /etc/defaults/rc.conf, apply some MD-specific changes, and
still let the user override the value in /etc/rc.conf if he wants to.
Martin Husemann
in rc.conf (and not what value it has after inheriting from defaults/rc.conf).
Maybe you can't use the same function verbatim, but a very close clone of
it (or even factor out the common part).
Martin
Iain Hibbert
> On 01.08.2011 17:28, Martin Husemann wrote:
> > See the bluetooth changed Iain did a few days ago, which had just the
> > same issue.
>
> We're not in the same situation: bluetooth is about migrating from the
> old rcvar variables to the "bluetooth" one. Mine is about keeping the
> same variable, but enable it on a per-arch basis.
you could change the "powerd" script name to something else, so that the
variable was changed.. ?
iain
Jean-Yves Migeon
> The situation is close: you want to know if there is an explicit setting
> in rc.conf (and not what value it has after inheriting from defaults/rc.conf).
The bluetooth checks are done on /etc/rc.conf through eval. Given that
/etc/rc.conf inherits its settings from /etc/defaults/rc.conf (see the
beginning of the file), I can't simply check whether the wannabee
powerd=NO line comes from /etc/rc.conf solely, or inherited from
/etc/defaults/rc.conf via ". /etc/defaults/rc.conf".
Have a look to a rc.conf, it will set its environment by executing
/etc/defaults/rc.conf first.
> Maybe you can't use the same function verbatim, but a very close clone of
> it (or even factor out the common part).
Well then, just show me how you would do that. Have a look at
rcvar_is_enabled():
http://nxr.netbsd.org/xref/src/usr.sbin/postinstall/postinstall#360
It executes /etc/rc.conf first (so that variables are set), which will
also executes /etc/defaults/rc.conf internally. Now how the script is
expected to know that "powerd=NO" came from /etc/rc.conf, and not
/etc/defaults/rc.conf?
Jean-Yves Migeon
> On Mon, 1 Aug 2011, Jean-Yves Migeon wrote:
>
>> On 01.08.2011 17:28, Martin Husemann wrote:
>>> See the bluetooth changed Iain did a few days ago, which had just the
>>> same issue.
>>
>> We're not in the same situation: bluetooth is about migrating from the
>> old rcvar variables to the "bluetooth" one. Mine is about keeping the
>> same variable, but enable it on a per-arch basis.
>
> you could change the "powerd" script name to something else, so that the
> variable was changed.. ?
Bluetooth expects the following:
1 - that obsolete variables aren't used any more in /etc/rc.conf. Not my
case.
2 - in case they are, warn user and ask him to update to bluetooth=YES.
Functionally, yes, it looks the same. However, Martin wanted me to add a
condition that renders the check silent if the user explicitly set
powerd=NO (or anything functionally equivalent) in /etc/rc.conf.
Problem: given the way /etc/rc.conf is designed, it will first include
/etc/defaults/rc.conf:
http://nxr.netbsd.org/xref/src/etc/rc.conf
How am I supposed to parse /etc/rc.conf via eval without polluting the
environment with default values? Given that /etc/defaults/rc.conf sets
powerd=NO by default: fail. And implementing a half-backed solution with
regexps is an ugly hack.
Mouse
> /etc/rc.conf, and not /etc/defaults/rc.conf?
I've seen the mailer variables handle this through setting the variable
to "check" and then seeing if it's still set that way later. See
rc.d/postfix in 4.0.1 (possibly other versions too; 4.0.1 is the one I
checked). Perhaps that could be adapted?
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Alan Barrett
> Quite frankly, I am more and more convinced that an additional
> /etc/defaults/rc.md.conf is the right fix then. This one
> could be included from /etc/defaults/rc.conf, apply some
> MD-specific changes, and still let the user override the value
> in /etc/rc.conf if he wants to.
I suggest making the contents of /etc/defaults/rc.conf be
machine-dependent. A script run at build time could create it
from MI and MD fragments. Put powerd=NO in some of the fragments,
and powerd=YES in other fragments.
--apb (Alan Barrett)
Jean-Yves Migeon
>> Now how the script is expected to know that "powerd=NO" came from
>> /etc/rc.conf, and not /etc/defaults/rc.conf?
>
> to "check" and then seeing if it's still set that way later. See
> rc.d/postfix in 4.0.1 (possibly other versions too; 4.0.1 is the one I
> checked). Perhaps that could be adapted?
Yep, I've seen them. IMHO it's overkill. I am not talking about a
sendmail => postfix migration, the modifications should remain reasonable.
David Holland
> > Now how the script is expected to know that "powerd=NO" came from
> > /etc/rc.conf, and not /etc/defaults/rc.conf?
>
> to "check" and then seeing if it's still set that way later. See
> rc.d/postfix in 4.0.1 (possibly other versions too; 4.0.1 is the one I
> checked). Perhaps that could be adapted?
That would make far too much sense...
--
David A. Holland
dhol...@netbsd.org
Jean-Yves Migeon
> On Mon, 01 Aug 2011, Jean-Yves Migeon wrote:
>> Quite frankly, I am more and more convinced that an additional
>> /etc/defaults/rc.md.conf is the right fix then. This one could be
>> included from /etc/defaults/rc.conf, apply some MD-specific changes,
>> and still let the user override the value in /etc/rc.conf if he wants to.
>
> I suggest making the contents of /etc/defaults/rc.conf be
> machine-dependent. A script run at build time could create it from MI
> and MD fragments. Put powerd=NO in some of the fragments, and
> powerd=YES in other fragments.
I am leaning towards this, although I am still unsure which one would be
best, between MI + MD => generate defaults/rc.conf, or have a MI
defaults/rc.conf which calls MD hooks if they are present.
There's no "one and only one" solution, let's see which one is less
invasive.
Steven Bellovin
On Aug 1, 2011, at 1:40 56PM, David Holland wrote:
> On Mon, Aug 01, 2011 at 12:55:09PM -0400, Mouse wrote:
>>> Now how the script is expected to know that "powerd=NO" came from
>>> /etc/rc.conf, and not /etc/defaults/rc.conf?
>>
>> I've seen the mailer variables handle this through setting the variable
>> to "check" and then seeing if it's still set that way later. See
>> rc.d/postfix in 4.0.1 (possibly other versions too; 4.0.1 is the one I
>> checked). Perhaps that could be adapted?
>
> That would make far too much sense...
>
How about this: read defaults/rc.conf *after* reading rc.conf, but use
: ${varname:=defaultvalue}
to set it. The semantics of it, in the ksh man page, are
${name:=word}
if name is set and not null, it is substituted, otherwise it is
assigned word and the resulting value of name is substituted.
but it works in out /bin/sh as well.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Christos Zoulas
Martin Husemann <mar...@duskware.de> wrote:
>On Tue, Aug 02, 2011 at 09:02:42PM +0200, Jean-Yves Migeon wrote:
>> Thoughts?
>
You should be able to use sysctl -q machdep.xen now
christos
Jean-Yves Migeon
> In article <20110802191...@mail.duskware.de>,
> Martin Husemann <mar...@duskware.de> wrote:
>> On Tue, Aug 02, 2011 at 09:02:42PM +0200, Jean-Yves Migeon wrote:
>>> Thoughts?
>>
>
> You should be able to use sysctl -q machdep.xen now
Thanks!
--
Jean-Yves Migeon
jeanyve...@free.fr
Jean-Yves Migeon
>> Quite frankly, I am more and more convinced that an additional
>> /etc/defaults/rc.md.conf is the right fix then. This one could be
>> included from /etc/defaults/rc.conf, apply some MD-specific changes,
>> and still let the user override the value in /etc/rc.conf if he wants to.
>
> I suggest making the contents of /etc/defaults/rc.conf be
> machine-dependent. A script run at build time could create it from MI
> and MD fragments. Put powerd=NO in some of the fragments, and
> powerd=YES in other fragments.
So I came back to this idea, but implemented it a bit differently. See
the patch attached.
In essence, /etc/defaults/rc.conf includes an arch file (conditioned on
its presence), etc/defaults/rc.arch.conf. This file is found under
src/etc.MACHINE/rc.arch.conf.
At install time, if present, it's installed as a regular config file.
Now why I chose to do this; I investigated two different ways:
- do like MAKEDEV in etc/Makefile, and use a skeleton template to merge
a MI + MD defaults/rc.conf file. This was quite heavyweight, and also
required to move away rc.conf from the CONFIGFILES entry in etc/defaults
(or it will get overwritten during configinstall), and modify
etc/Makefile a bit.
- try to delegate the build logic (like done with the mtree subtree).
Changes within etc/Makefile are minimal, but this involved some
heavyweight tinkering in etc/defaults/Makefile as I would have to manage
two files (a MI one: rc.conf.base, and a MD one: rc.conf.MACHINE). This
would lead to rc.conf rename, for no big win in the end.
The proposed patch adresses all comments I have received so far, it
avoids etcupdate/postinstall modifications, end-user configuration has
still the last word with /etc/rc.conf, and brings a little advantage to
my previous suggestion: I am conditioning powerd=YES to the presence of
machdep.xen, so i386/amd64 users that aren't using Xen shouldn't be
impacted by this new dependency.
Thoughts? I'll be AFK for quite some time starting tomorrow afternoon,
so this leaves a few days for review...
Martin Husemann
> Thoughts?
I like this!
Martin
Alan Barrett
>On 01.08.2011 18:57, Alan Barrett wrote:
>> I suggest making the contents of /etc/defaults/rc.conf be
>
>So I came back to this idea, but implemented it a bit differently. See
>the patch attached.
>
>In essence, /etc/defaults/rc.conf includes an arch file (conditioned on
>its presence), etc/defaults/rc.arch.conf. This file is found under
>src/etc.MACHINE/rc.arch.conf.
>
>At install time, if present, it's installed as a regular config file.
That's not an implementation of my idea. My idea is to give the
end user a single /etc/defaults/rc.conf file.
If merging file fragments at build time is too complex, then you
could make a decision at run time, since /etc/defaults/rc.conf is
a shell script:
case "$(/sbin/sysctl -n hw.machine_arch)" in
foo|bar|baz) powerd=YES ;;
*) powerd=NO ;;
esac
--apb (Alan Barrett)
Steven Bellovin
On Aug 2, 2011, at 10:47 21PM, Mouse wrote:
>> How about this: read defaults/rc.conf *after* reading rc.conf, but use
>
>> : ${varname:=defaultvalue}
>
>> to set it.
>
> Nice idea, but how do you deal with all the existing rc.confs which
> have the ". /etc/defaults/rc.conf" _first_, rather than _last_?
>
> You could make /etc/defaults.rc.conf empty and put the defaults in
> another file, but then how do you get that file included in the legacy
> rc.confs?
postinstall? etcupdate? Let's first figure out where we want to go,
and then figure out how to get there.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Jean-Yves Migeon
> On Tue, 02 Aug 2011, Jean-Yves Migeon wrote:
>>On 01.08.2011 18:57, Alan Barrett wrote:
>>> I suggest making the contents of /etc/defaults/rc.conf be
>>
>>So I came back to this idea, but implemented it a bit differently.
>> See
>>the patch attached.
>>
>>In essence, /etc/defaults/rc.conf includes an arch file (conditioned
>> on
>>its presence), etc/defaults/rc.arch.conf. This file is found under
>>src/etc.MACHINE/rc.arch.conf.
>>
>>At install time, if present, it's installed as a regular config file.
>
> user a single /etc/defaults/rc.conf file.
Which is still the case, except that it parses an additional file.
Yeah, we could endlessly debate on this :)
> If merging file fragments at build time is too complex, then you
> could make a decision at run time, since /etc/defaults/rc.conf is a
> shell script:
>
> case "$(/sbin/sysctl -n hw.machine_arch)" in
> foo|bar|baz) powerd=YES ;;
> *) powerd=NO ;;
> esac
I'd like to keep src/etc/defaults/rc.conf untouched from all sort of MD
hooks/machinery. I am still looking at bsd.files.mk and some Makefile
magic to make the whole thing work by generating a defaults/rc.conf from
different fragments, but my current tries look still ugly.
jean-Yves Migeon
>>> How about this: read defaults/rc.conf *after* reading rc.conf, but
>>> use
>>
>>> : ${varname:=defaultvalue}
>>
>>> to set it.
>>
>> Nice idea, but how do you deal with all the existing rc.confs which
>> have the ". /etc/defaults/rc.conf" _first_, rather than _last_?
IMHO that should have been done that way first. But read on.
>> You could make /etc/defaults.rc.conf empty and put the defaults in
>> another file, but then how do you get that file included in the
>> legacy
>> rc.confs?
>
> postinstall? etcupdate? Let's first figure out where we want to go,
> and then figure out how to get there.
Indeed; unfortunately it's problematic to have something working
acceptably in postinstall/etcupdate that won't bork up the end-user's
/etc/rc.conf. As explained in rc.conf(5), end-user may put whatever he
wants inside, and this can lead to complicated parsing/editing.
IMHO postinstall/etcupdate shouldn't push big changes in /etc/rc.conf:
risk being either an incorrect /etc/rc.conf which can cripple a boot
entirely. Or have something that requires user's intervention to fix and
is not as simple as "don't use foo because its obsolete. use bar-YES
instead".
With all the potential side affects hiding behind, I am not prepared to
make such a paradigmal shift (e.g. moving from defaults overriden by
end-user to end-user overriden by defaults in case it's not set).
--
Jean-Yves Migeon
j...@NetBSD.org
Steven Bellovin
On Aug 3, 2011, at 10:55 33PM, jean-Yves Migeon wrote:
> On Wed, 3 Aug 2011 22:26:31 -0400, Steven Bellovin wrote:
>>>> How about this: read defaults/rc.conf *after* reading rc.conf, but use
>>>
>>>> : ${varname:=defaultvalue}
>>>
>>>> to set it.
>>>
>>> Nice idea, but how do you deal with all the existing rc.confs which
>>> have the ". /etc/defaults/rc.conf" _first_, rather than _last_?
>
> IMHO that should have been done that way first. But read on.
>
>>> You could make /etc/defaults.rc.conf empty and put the defaults in
>>> another file, but then how do you get that file included in the legacy
>>> rc.confs?
>>
>> postinstall? etcupdate? Let's first figure out where we want to go,
>> and then figure out how to get there.
>
> Indeed; unfortunately it's problematic to have something working acceptably in postinstall/etcupdate that won't bork up the end-user's /etc/rc.conf. As explained in rc.conf(5), end-user may put whatever he wants inside, and this can lead to complicated parsing/editing.
>
> IMHO postinstall/etcupdate shouldn't push big changes in /etc/rc.conf: risk being either an incorrect /etc/rc.conf which can cripple a boot entirely. Or have something that requires user's intervention to fix and is not as simple as "don't use foo because its obsolete. use bar-YES instead".
>
> With all the potential side affects hiding behind, I am not prepared to make such a paradigmal shift (e.g. moving from defaults overriden by end-user to end-user overriden by defaults in case it's not set).
>
I suspect that my idea will give the same result for any rc.conf that
doesn't check for already-set -- and I don't see why any should make
such a check.
Here are my proposed semantics for the upgrade code.
First -- these three lines are the first non-null, non-comment lines
in rc.conf:
if [ -r /etc/defaults/rc.conf ]; then
. /etc/defaults/rc.conf
fi
If that isn't true, print a message and don't autoupgrade.
Second -- look for "exit" in rc.conf. Its presence denotes
user complexity; scream for help.
Third -- look for "if" (except as above), "for", "while", "case",
"test", or "[" as commands; again, they represent a complex case,
so scream for help.
Fourth -- delete the standard code from the beginning (along with
its comments) and add them to the end.
I note that etcupdate today is fully interactive and postinstall
already doesn't handle certain fairly mundane tasks (like adding
new system users to /etc/master.passwd. I don't think this situation
is particularly different.
--Steve Bellovin, https://www.cs.columbia.edu/~smb
Mouse
> acceptably in postinstall/etcupdate that won't bork up the end-user's
> he wants inside, and this can lead to complicated parsing/editing.
Indeed. I've resorted to real shell code in rc.conf on a few
occasions. Probably my msot complex rc.conf setup is my mobile
machine's, which uses newbtconf and, for most configs, its rc.conf does
". /etc/etc-common/rc.conf" and then adds a few settings; the common
rc.conf defines a shell function, among other things. I've also done
things in rc.conf like "for i in `ifconfig -l`; do ... done".
Maybe I'm the only person who does that sort of stuff. But I'm
inclined to doubt it.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
--