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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
