On Monday 12 July 2010 23:41:25 Denys Vlasenko wrote: > 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.
By the way, I just dropped 1.17.0 into my build system and: CC miscutils/rfkill.o miscutils/rfkill.c:10:26: error: linux/rfkill.h: No such file or directory miscutils/rfkill.c: In function 'rfkill_main': miscutils/rfkill.c:21: error: storage size of 'event' isn't known miscutils/rfkill.c:46: error: 'RFKILL_TYPE_ALL' undeclared (first use in this function) miscutils/rfkill.c:46: error: (Each undeclared identifier is reported only once miscutils/rfkill.c:46: error: for each function it appears in.) miscutils/rfkill.c:65: error: 'RFKILL_EVENT_SIZE_V1' undeclared (first use in this function) miscutils/rfkill.c:105: error: 'RFKILL_OP_CHANGE_ALL' undeclared (first use in this function) miscutils/rfkill.c:110: error: 'RFKILL_OP_CHANGE' undeclared (first use in this function) miscutils/rfkill.c:21: warning: unused variable 'event' Doesn't like Ubuntu 9.04, I'm guessing. > > 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. Sure. Ask for a patch. :) > > 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?". *shrug* > > 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. Yes, but makes them visible _where_? Is the system-utilities menu (between "more" and "linuxraid" really the appropriate place to stick this stuff? At the very least, there should be a sub-menu. (And configuration options that aren't attached to an applet general get segregated a bit from the Big Long List of Applets.) But this is obviously a work in progress. Hasn't even got help entries yet. (Part of my confusion was having to dig through the source to figure out what all that was for.) > > 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 More or less Linus Torvalds's reaction, yes: http://kerneltrap.org/node/6884 > > 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" > " Considering that the output of /proc/acpi/event is things like: button/power PBTN 00000080 00000001 I just made a really small shell script that did it last time I cared (2006?), doing something like "while read one two < /proc/acpi/event" and then some simple if cases with string matching, or something. It was a while ago, don't remember the details... I'm guessing you're looking at the magic binary data from /dev/event, whereas I like human-readable text. (Magic binary data is the windows approach, human readable text is unix.) Still, there's an existing acpid which you decided busybox needed for some reason, so you're being compatible with it. *shrug* > > 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. So it couldn't work if it went through libc which wouldn't have the syscalls or ioctl structures, but you can hand-parse binary blobs out of sysfs, and you consider that worth doing? Personally, I don't. I'm big into the "this is not our problem" approach to determining the boundaries of a project, and segregating stuff into some kind of platform.h when it is our problem so the _rest_ of the code doesn't have to care. (You're the one who'll have to maintain it, but _everybody_ will have to deal with it when it breaks. And code that doesn't exist can't break.) I was attracted not just to busybox's small size, but to its _simplicity_. You can't grow forever and stay simple. Busybox wasn't just about "can we do this more efficiently", it was about "do we actually need to do this in the first place", "and "how can we get away with not doing this?" > > 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 Check. > * 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? My first idea is adding a FAQ entry with the rationale: I use a "trimconfig" which "inadvisable" features, starting with: CONFIG_FEATURE_ASSUME_UNICODE=n CONFIG_FEATURE_CLEAN_UP=n CONFIG_SELINUX=n CONFIG_PAM=n CONFIG_FEATURE_PREFER_APPLETS=n CONFIG_STATIC=n CONFIG_PIE=n CONFIG_NOMMU=n CONFIG_BUILD_LIBBUSYBOX=n Things like selinux and pam require optional stuff on the host and won't work without them. Things like PIE, static linking, nommu, and libbusybox are things you know if you want and can explicitly request. FEATURE_CLEAN_UP is a debug thing, and unicode is both a "needs environmental support" thing and something that (I think) belongs at the x11/qt/gtk level, not most command line tools. But that last one's a bit of a judgement call, I admit. The following code is archaic and dead, quite possibly removed by now, I need to check: CONFIG_FEATURE_MTAB_SUPPORT=n CONFIG_FEATURE_DEVFS=n CONFIG_DEVFSD=n # Switch off debug stuff CONFIG_DEBUG=n CONFIG_WERROR=n CONFIG_INSTALL_NO_USR=n CONFIG_DEBUG_TFTP=n CONFIG_FEATURE_UDHCP_DEBUG=n # This doesn't build on some non-x86 targets (such as m68k). CONFIG_TASKSET=n # This doesn't build under Knoppix 5 CONFIG_INOTIFYD=n # This doesn't even build for i686 on Ubuntu 8.04. CONFIG_FLASHCP=n CONFIG_FLASH_LOCK=n CONFIG_FLASH_UNLOCK=n CONFIG_FLASH_ERASEALL=n # Contains a hardwired #ifdef staircase of known targets, breaks on hexagon. CONFIG_FEATURE_OSF_LABEL=n # Doesn't build on SLES 10 CONFIG_ACPID=n # Doesn't build on Ubuntu 9.04. CONFIG_RFKILL=n > > 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? 5 years sounds like a reasonable ballpark, but it won't happen by itself. I just had to switch RFKILL off to build 1.17.0 on my Ubuntu 9.04 laptop. > > Stated in my usual incoherent ramble... > > Heh, I wish I'd be so talkative. Many different people have said variants of "I apologize for writing a long letter/book/series, because I didn't have time to write a short one". Thoreau, Mark Twain, Voltaire, Geroge Bernard Shaw all said it. Blaise Pascal seems to have been first ("Letters Provincials #16", in 1657), but I'm sure some greek or roman beat him to it by at least 1000 years... 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
