Review of the last few applied patches...

[Rob Landley]

On Friday 19 May 2006 1:51 pm, Bernhard Fischer wrote:
> On Fri, May 19, 2006 at 01:28:05PM -0400, Rob Landley wrote:
> >Review of yesterday's committed patches...
>
> Rob, vodz correctly pointed out that we may have a problem with your fix
> in readlink.c if BUFSIZ is too small -- much smaller than PATH_MAX.

It's not ideal, true.  I'm still pondering a bb_realpath() that platform.h 
either #defines as realpath() if it can handle NULL, or links to a libbb 
function...

> On a related note..
> I was thinking about making our internal BUFSIZ configurable via
> "Busybox Library Tuning". What do you think?

Is our BUFSIZ used for anything but the global common buffer?  I'm pondering 
how to merge that in with the "union of global structures" thing I'm slowly 
wandering twoards with sed.c and mdev.c...

> PS:
> Currently, there are alot of different sizes used, to name just a few:
> decompress_bunzip2.c:#define IOBUF_SIZE 4096
> sum.c:#define MY_BUF_SIZE 8192
> pipe_progress.c:#define PIPE_PROGRESS_SIZE 4096
> inetd.c:#define BUFSIZE 4096
> httpd.c:# define PIPESIZE 4096

Can these all be made to use bb_common_bufsiz1?  Or do they need a #define to 
make their own buffer with?

4096 is PAGE_SIZE, and there's a real reason to have something be that size 
(access to that size chunks tends to be optimized on modern processors.  Of 
course with malloc() overhead it probably tends to straddle pages anyway, 
so...)

> Some of these are always for the same kind of uses (pipe, block I/O,
> etc).

Is there any way to do whatever they're doing in common code?  (Which may just 
mean "use bb_common_bufsiz1 for the buffer".  (The outlier's 
decompress_bunzip2, which could potentially be called from some of the 
others, and thus the two uses of the buffer stomp each other...)

Rob
-- 
Never bet against the cheap plastic solution.