0.9.30.1 review - svn 24052

Rob Landley rob at landley.net
Mon Feb 16 03:06:21 UTC 2009


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


More information about the uClibc mailing list