acpid in 1.16.2 doesn't build on SLES 10.

Tue Jul 13 04:41:25 UTC 2010

On Monday 12 July 2010 20:53, Rob Landley wrote:
> On Sunday 11 July 2010 23:24:45 Denys Vlasenko wrote:
> > On Sunday 11 July 2010 21:48, Rob Landley wrote:
> > > Why are mount and acpid different?
> >
> > You know the answer. Because someone submitted the patch to add
> > those #defines to mount.c.
> 
> Actually git credited you with the patch, and a quick glance at the git 
> comment didn't credit anyone else, so I thought it was you.  (Looking more 
> closely I see you were taking existing portability code out of platform.h code 
> and spreading it around into the rest of the code.  I'm not even going to ask 
> why.)

Right. Such #defines are not added proactively, but on
as-needed basis: someone reports a build problem -> #define is added.
Which makes sense - otherwise we'd have tons of #defines
almost in every file, just in case. Which would hurt readability.
That's what I was trying to say.

> > If you want such defines in acpid.c, you can send the patch.
> > Or you can add it yourself.
> > Or you can simply ask me "please add #ifndef SW_LID #define SW_LID
> > to acpid.c", ...
> >
> > > I can switch off acpid.  I haven't used defconfig in years because it's
> > > become useless to me, I start with allyesconfig and apply a trimconfig
> > > file that switches off the stuff that's broken in some context or other.
> > >
> > > I'm just wondering what the reasoning for doing different things in
> > > different applets is.
> >
> > ...instead of sort of accusing me of evil plot to make acpid.c
> > to not build on SLES 10.  Trust me, I do not have such plan! :D
> 
> I'm not trying to accuse you of an evil plot, sorry if it came across that 
> way.

I knew that. I mean, it sounds that way a bit.

> The patch is trivial enough that pointing out the issue and coming up  
> with an #ifdef are almost equivalent,

Yes. Technically, it is equivalent. Socially, it is not.
The sad truth, even in IT we have to deal with social stuff a lot.

> You set busybox policy these days, and I'm trying to ask policy questions.  
> (And I'm trying to ask _questions_ rather than say "I think we should do it 
> THIS way", because I don't wanna be bossy.

I usually phrase it this way: "I propose (such and such solution). Other ideas?".

> One question is about defconfig: I've never quite understood what your criteria 
> for putting stuff in defconfig is, and your initial suggestion that defconfig 
> isn't intended to be particularly portable kind of confused me further.
>
> As for the applet in question, I'm really not that familiar with what it does.  
> Possibly acpid falls under the same category as those weird "select 
> 32bit/64bit mode" commands for x86-64, whatever they were called.  (Searching 
> for them in menuconfig I ran into the dozen "FEATURE_VOLUMEID_BLAH" entries 
> which are attached to:
> 
>   config VOLUMEID
>         bool #No description makes it a hidden option
>         default n
> 
> So the group entry is hidden but the individual "Ext filesystem" and "btrfs 
> filesystem" ones aren't, and I can't clean that up because I have no idea what 
> you're trying to do with it.)

CONFIG_VOLUMEID is used to enable compilation of common modules for
volume format/filesystem detection:

lib-$(CONFIG_VOLUMEID) += volume_id.o util.o

It is automatically turned on when used selects blkid, findfs or FEATURE_MOUNT_LABEL,
which makes FEATURE_VOLUMEID_foo options visible.
User does not really need to see VOLUMEID per se in menuconfig.

> Anyway, back to the point: acpid might be x86-only since ACPI itself was 
> Intel's attempt to get away from BIOSes written in 16-bit 8086 assembly 
> language (because those made the itanic look bad, so intel launched a major 
> denial-of-reality effort to try to make Itanic sink slower), and thus they came 
> up with BIOSes written in a new bytecode that was neither Java nor Fortran, 
> and everybody threw up on it and only fished the data tables out of it (and 
> then System Management Mode happened and I <strike>fled in terror</strike> 
> stopped paying attention to the non-coreboot stuff).

Gaack

> So I'm out of the loop on acpi these days, and I dunno what acpid is actually 
> doing.

Me neither. I think it mimics "standard" one: http://linux.die.net/man/8/acpid
Looks like it's useful for things like:

"Example

This example - placed in /etc/acpi/events/power -
will shut down your system if you press the power button.

event=button/power.*
action=/usr/local/sbin/power.sh "%e"
"

> It's possible that acpid is fishing around in /proc or /sys interfaces  
> that are only available on current kernels, so adding the #ifdef is pointless.  
> (The result would compile, but never actually do anything useful.)

Since there is always a possibility that machine where acpid is _run_
does have new enough kernel, regardless of how old kernel headers were
on the _build_ machine. So, such #defines are useful.

> Or, it's possible that the ACPI interface has become the generic way for Linux 
> to report power events to userspace, even when the back-end is something else, 
> and thus arm and mips and such care, and maybe that's how remaining battery 
> life is reported on the HTC Inedible, and thus it _should_ be in defconig.  I 
> don't know.  http://lesswatts.org/projects/acpi is a bit of an argument 
> against it, but that's an Intel site so it probably wouldn't support mips and 
> such even if the kernel did.
> 
> So "should this build portably" and "should this be in defconfig" were actually 
> two separate questions, which I wasn't clear on.  I was focusing on "should 
> this be in defconfig" (because I don't know), but I'm still trying to figure out 
> what defconfig is actually for these days.
> 
> > Please try this patch on SLES 10 and let me know if it doesn't help.
> 
> The patch is overkill.  The only symbol I needed to #define to build acpid was 
> SW_LID.  Three lines:
> 
> --- a/util-linux/acpid.c
> +++ b/util-linux/acpid.c
> @@ -9,9 +9,12 @@
>  #include "libbb.h"
>  
>  #include <linux/input.h>
> +#ifndef SW_LID
> +# define SW_LID        0x00
> +#endif
>  #ifndef SW_RFKILL_ALL
>  # define SW_RFKILL_ALL 3
>  #endif
> 
> Of course that's to get it to build on sles10.  On sles9 ionice dies because 
> SYS_ioprio_set and SYS_ioprio_get are undeclared, but regression testing in 
> general is a can of worms, and a policy issue.
> 
> Back in 2006, I used to use Red Hat 9 as the metric, "you must be this tall 
> for busybox to care about you as a build environment."  But that was only a 3 
> year old version at the time, released April 2003.  These days, it's probably 
> fallen off the bottom of what most people care about.
> 
> I'm more interested in the policy issues than any specific bug.  These days I'd 
> probably personally use Ubuntu 6.06 LTS as the regression test version, since 
> Cannonical is still supporting that through June of next year according to 
> https://wiki.ubuntu.com/Releases and it's currently the most popular Linux 
> (about 40% market share among Linux distros last I heard).
> 
> According to /proc/version, the kernel in SLES 9 was built in July 2006, and 
> the one in SLES 10 was built in May 2008.  (These machines would be honey pots 
> if they weren't internal build servers behind a firewall.)  So they're roughly 
> on par with Ubuntu 6.06, more or less.  (They're also what I have lying around 
> at work.)
> 
> So, three policy questions:
> 
> 1) What should and shouldn't be in defconfig.

defconfig should have almost all options enabled; except these:
* debug build options
* options which introduce incompatible behavior (e.g. "standalone shell" option)
* options which are likely to require very vecent kernel headers
  (these options are to be turned on in future)
Other ideas?

> 2) How portable should acpid be?

Have no idea...

> 3) How old a system are we interested in regression testing on?

Say, about 5 years old? 4 years old?

> Stated in my usual incoherent ramble...

Heh, I wish I'd be so talkative.
-- 
vda