On Wednesday 14 July 2010 01:20:51 Denys Vlasenko wrote:
> On Wednesday 14 July 2010 00:07, Rob Landley wrote:
> > 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.
>
> I'd like to fix them all in 1.17.1. Do any other applets give you this
> trouble?
I've got the server building all targets now. (x86 worked, arm didn't, not
sure why yet, could easily be something I screwed up at my end over the
weekend.)
I hope to get the nightly regression testing up and running in the next couple
days. That should help find these earlier. (And I owe you 1.17.0 binaries for
all targets. Do you still want 1.16.2 binaries, or just the most recent?)
> Yes. I didn't notice this ugliness since I never use menuconfig.
> Please try this:
>
> http://busybox.net/downloads/fixes-1.17.0/busybox-1.17.0-volumeid.patch
Looks fine.
> > 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*
>
> Vladimir wanted it:
>
> Date: Sat Nov 29 09:05:50 2008 +0000
> acpid: new applet by Vladimir. +737 bytes
>
> I decided to make one of our active patch submitters a bit
> happier/successful in whatever he is doing using busybox. Perhaps because I
> was lazy and didn't bother researching whether it can be writted in
> shell...
*shrug* It can be turned off. My concern is it not breaking defconfig built
on
other hosts or for other targets.
If I could actually use defconfig instead of my allnoconfig
KCONFIG_ALLCONFIG=trimconfig thing, that would be an improvement...
> > 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?"
>
> Unfortunately, that approach would severely limit busybox's
> possible user base: it will exclude desktop users, which is A LOT.
>
> We can target the "how can we get away with not doing this?"
> userbase relatively easily by supporting a separate
> miniconfig.
It's little things. For example, realpath has been available as "readlink -f"
for years. In toybox, I would have had realpath be a sub-option of readlink
that added an alias. In busybox, it's a second applet that shares no code
with the first.
(See attached toybox readlink.c and then a howto.patch for how I'd have added
realpath on top of it. The patch is untested, but took me about 4 minutes.)
> > > > 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
>
> (It's renamed to CONFIG_UNICODE_SUPPORT now)
> I lean more to enabling it.
*shrug* I disabled most but not all internationalization support in the
uClibc I'm building, so I dunno if it's got sufficient unicode stubs or not.
Let's see..
I switched it back on and it built, and booted to a shell prompt where I could
run "ls -l", so I'm calling it good. :)
> > 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
>
> These already default to n.
Ok.
> > 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
>
> Not really. We have full internal implementation now.
> No libc support is necessary. You can build uclibc without locale support
> and still build unicode-aware busybox against it.
You're right, I just confirmed this.
> > and
> > something that (I think) belongs at the x11/qt/gtk level, not most
> > command line tools.
>
> Apart from those people who really need to "rm HiFi-Запоминай.MP3"
> from the shell command line, and they want line editing to not go belly up
> when confronted with multi-byte characters. Not to mention Israeli users,
> who have much pain entering filenames in Hebrew in reverse order.
> Try it, and you'll understand.
I don't have strong objections to unicode, of the 8 gazillion
internationalized character sets I've seen it's the _only_ sane one.
But the internationalization bits that force you to set an environment
variable to get "sort" to stop sudenly being case insensitive, those were a
bad idea.
> > 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
>
> These already default to n.
>
> > # Switch off debug stuff
> >
> > CONFIG_DEBUG=n
> > CONFIG_WERROR=n
> > CONFIG_INSTALL_NO_USR=n
> > CONFIG_DEBUG_TFTP=n
>
> These already default to n.
>
> > CONFIG_FEATURE_UDHCP_DEBUG=n
>
> It's renamed to UDHCP_DEBUG in 1.17.0, changed to be an int
> and it's not a debug option (as in "do not use in production!"):
>
> Verbosity can be increased with multiple -v options.
> This options controls how high it can be cranked up.
> Bigger values result in bigger code. Levels above 1
> are very verbose and useful for debugging only.
>
> I suggest setting it to 1 or 2. Diagnosing DCHP problems with it
> is so much easier...
>
> > # This doesn't build on some non-x86 targets (such as m68k).
>
> Disabling for 1.17.1:
> http://busybox.net/downloads/fixes-1.17.0/busybox-1.17.0-build_system.patch
>
> > CONFIG_TASKSET=n
>
> Disabling for 1.17.1
>
> > # This doesn't build under Knoppix 5
> >
> > CONFIG_INOTIFYD=n
>
> Disabling for 1.17.1
>
> > # 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
>
> Disabling for 1.17.1
>
> > # Contains a hardwired #ifdef staircase of known targets, breaks on
> > hexagon.
> >
> > CONFIG_FEATURE_OSF_LABEL=n
>
> Defaults to n in 1.17.0 already
>
> > # Doesn't build on SLES 10
> >
> > CONFIG_ACPID=n
>
> fixed?
> http://busybox.net/downloads/fixes-1.17.0/busybox-1.17.0-acpid.patch
I'll try swapping the trimconfig for updated defconfig later today and report
on
the results. For now, lunch break over, back on my head...
> > # Doesn't build on Ubuntu 9.04.
> >
> > CONFIG_RFKILL=n
>
> Disabling for 1.17.1
Thanks,
Rob
--
GPLv3: as worthy a successor as The Phantom Meanace, as timely as Duke Nukem
Forever, and as welcome as New Coke.
/* vi: set sw=4 ts=4:
*
* readlink.c - Return string representation of a symbolic link.
*
* Copyright 2007 Rob Landley <[email protected]>
*
* Not in SUSv3.
USE_READLINK(NEWTOY(readlink, "<1f", TOYFLAG_BIN))
config READLINK
bool "readlink"
default n
help
usage: readlink
Show what a symbolic link points to.
config READLINK_F
bool "readlink -f"
default n
depends on READLINK
help
usage: readlink [-f]
-f Show full cannonical path, with no symlinks in it. Returns
nonzero if nothing could currently exist at this location.
*/
#include "toys.h"
void readlink_main(void)
{
char *s;
// Calculating full cannonical path?
if (CFG_READLINK_F && toys.optflags) s = realpath(*toys.optargs, NULL);
else s = xreadlink(*toys.optargs);
if (s) {
xputs(s);
if (CFG_TOYBOX_FREE) free(s);
} else toys.exitval = 1;
}
diff -r 35c8beb54800 toys/readlink.c
--- a/toys/readlink.c Sun Feb 28 14:11:41 2010 -0600
+++ b/toys/readlink.c Wed Jul 14 11:42:45 2010 -0500
@@ -7,6 +7,7 @@
* Not in SUSv3.
USE_READLINK(NEWTOY(readlink, "<1f", TOYFLAG_BIN))
+USE_READLINK_REALPATH(OLDTOY(realpath, readlink, "<1", TOYFLAG_BIN))
config READLINK
bool "readlink"
@@ -21,10 +22,19 @@
default n
depends on READLINK
help
- usage: readlink [-f]
+ usage: readlink [-f] NAME
-f Show full cannonical path, with no symlinks in it. Returns
nonzero if nothing could currently exist at this location.
+
+config READLINK_REALPATH
+ bool "realpath"
+ default n
+ depends on READLINK_F
+ help
+ usage: realpath NAME
+
+ Show full cannonical path, with no symlinks in it.
*/
#include "toys.h"
@@ -35,8 +45,11 @@
// Calculating full cannonical path?
- if (CFG_READLINK_F && toys.optflags) s = realpath(*toys.optargs, NULL);
- else s = xreadlink(*toys.optargs);
+ if ((CFG_READLINK_REALPATH && toys.which->name[3]=='l') ||
+ (CFG_READLINK_F && toys.optflags))
+ {
+ s = realpath(*toys.optargs, NULL);
+ } else s = xreadlink(*toys.optargs);
if (s) {
xputs(s);
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
