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.)
> 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. The patch is trivial enough that pointing out the issue and coming up
with an #ifdef are almost equivalent, my question was really "How do you want
to handle this issue I tripped over".
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'm probably screwing that part up
horribly.)
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.)
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).
So I'm out of the loop on acpi these days, and I dunno what acpid is actually
doing. 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.)
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.
2) How portable should acpid be?
3) How old a system are we interested in regression testing on?
Stated in my usual incoherent ramble...
Rob
--
GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem
Forever, and as welcome as New Coke.
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
