On Sunday 15 February 2009 17:29:00 Bernhard Reutner-Fischer wrote: > On Sat, Feb 14, 2009 at 05:00:06PM -0600, Rob Landley wrote: > >Svn 24052 is a poorly-defined patch mixes at least four seemingly > > unrelated things: > > > >1) It adds UCLIBC_HAS_SSP support to various makefile like nsl and > > libresolv. > > r24955
Doesn't svn 24956 claim to be 24955 from trunk? 24052 is also 24955? > >2) It uses #if 0/#endif to chop out a largeish portion of > >include/sys/sysinfo.h (no idea why), and it adds 8 zillion #ifdef > >__UCLIBC_LINUX_SPECIFIC__ things when linux is the only target uClibc has > >historically _ever_ supported. > > The target has nothing to do with that knob, just the API. *shrug* Ok. A line to that effect in the help entry might be good. Something along the lines of: These functions are not available on non-linux systems, so if you're only running portable software you probably don't need them taking up space. > >3) It renames a local variable in libc/inet/ifaddrs.c:map_newlink() from > >"index" to "idx". > > r24025 Ah, makes a warning go away. Ok. > >4) It adds and #ifdef __UCLIBC_LINUX_SPECIFIC__ to a lot of places that > >already have a __USE_GNU. Apparently, this needed a synonym. > > > >I'm confused why UCLIBC_LINUX_SPECIFIC exists in the first place since > > Linux is the only platform uClibc has ever supported and you can't build > > the sucker > > This has nothing to do with the target platform but allows for removing > linux specific API hunks that are non-standard. A switch to remove this identifiable group of APIs makes as much sense as any of the other size reduction switches uClibc has. I guess this is just a way of grouping 'em... > >without Linux kernel headers, but I guess it's just one more way of > > defining a set of optional functionality to remove for size reasons. But > > in this case, it's adding stuff to _headers_ (making them larger, not > > removing any code from the binary). > > > >I also note that the help for the config entry for UCLIBC_LINUX_SPECIFIC > > from 0.9.30 provides an explicit list of functions to be inexplicably > > removed: fstatfs(), inotify_*(), ioperm(), iopl(), madvise(), > > modify_ldt(), personality(), ppoll(), setresuid(), signalfd(). This > > presumably extends that list (one of the few places it's not merely a > > synonym for __USE_GNU is where it inexplicably chops out vhangup()), but > > this patch does not modify that help entry. > > Right, i've apparently forgotten to add them to the helptext, i'll add > them unless you beat me to it. I have no idea how to check stuff into an svn branch, so I'll happily let you do it. :) I do note that the development branch has a much bigger list already, so presumably that's fine... > >This patch is a bugfix? For _what_? > > cleanness. Do whitespace and refactoring patches belong in a bugfix-only release too? (They're for cleanness as well...) *shrug* Just wondering what the criteria are... Rob _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
