| Age | Commit message (Collapse) | Author |
|---|
|
end of file, causing it to hang on corrupted input.
|
|
|
|
the user's umask
|
|
Hi!
I've created a patch to busybox' build system to allow building it in
separate tree in a manner similar to kbuild from kernel version 2.6.
That is, one runs command like
'make O=/build/some/where/for/specific/target/and/options'
and everything is built in this exact directory, provided that it exists.
I understand that applyingc such invasive changes during 'release
candidates' stage of development is at best unwise. So, i'm currently
asking for comments about this patch, starting from whether such thing
is needed at all to whether it coded properly.
'make check' should work now, and one make creates Makefile in build
directory, so one can run 'make' in build directory after that.
One possible caveat is that if we build in some directory other than
source one, the source directory should be 'distclean'ed first.
egor
|
|
|
|
dev_t. This is especially important now that the user space concept of a dev_t
and the kernel concept of a dev_t are divergant. The only bit of user space
allowed to know the number of major and minor bits is include/sys/sysmacros.h
(i.e. part of libc). When used with a current C library and a 2.6.x kernel,
this fix should allow BusyBox to support wide device major/minor numbers.
-Erik
|
|
|
|
|
|
This is a bulk spelling fix patch against busybox-1.00-pre10.
If anyone gets a corrupted copy (and cares), let me know and
I will make alternate arrangements.
Erik - please apply.
Authors - please check that I didn't corrupt any meaning.
Package importers - see if any of these changes should be
passed to the upstream authors.
I glossed over lots of sloppy capitalizations, missing apostrophes,
mixed American/British spellings, and German-style compound words.
What is "pretect redefined for test" in cmdedit.c?
Good luck on the 1.00 release!
- Larry
|
|
|
|
rename unzip.c to decompress_unzip.c
|
|
|
|
s/fileno\(stdout\)/STDOUT_FILENO/g
|
|
|
|
it seemed like a good idea at the time.
|
|
|
|
interpreted, we cannot depend on the file type being set in the mode
field.
|
|
|
|
|
|
|
|
|
|
much, modified patch from Bastian Blank
|
|
in the tarball that point to them.
-Erik
|
|
|
|
archive_xread can be replaced with bb_full_read, and archive_copy_file
with bb_copyfd*
bb_copyfd is split into two functions bb_copyfd_size and bb_copyfd_eof,
they share a common backend.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
open_transformer(), common code for pipe+fork.
Function pointer for read() no longer needed.
Allow inflate to be initialised with a specified buffer size to avoid
over-reading.
Reset static variables in inflate_get_next_window to fix a bug where
only the first file in a .zip would be be extracted.
|
|
|
|
files to compute incorrect crc and length for gzip
|
|
|
|
|
|
|
|
|
|
support compile. Glenn, you may want to verify this.
-Erik
|
|
|
|
Use the old fork() method of tar compression support, rather than
read_bz2....
- (*uncompress)(int in, int out) seems like a more natural interface
for compression code.
- it might improve performance by seperating the work into one cpu
bound and one io bound process.
- There is extra code required to do read_[gz|bunzip] since (*uncompress)(int in,
int out) will normally be used by the standalone compression applet.
There have been problems with this method so if you see a "Short read"
error let me know.
|
|
|
|
|
|
|
|
This hides a bug related to the new bunzip code in the tar and dpkg[-deb]
applets.
It will also reduce compile time a little as some unused files wont be
compiled.
|
|
additional changes (primarily lots of comments) from Rob Landley.
|
|
Hello Rob,
Here's a patch to your bunzip-3.c file. Nice work btw.
One minor bug fix... checking for error return when read()ing.
Some size/performance optimizations as well. One instance of
memset() seems unnecssary. You might want to take a look.
Anyway, on my machine, decompressing linux-2.6.0-test7.tar.bz2
to /dev/null gave the following times:
bunzip-3.c bzcat (system) bunzip-3.c (patched)
real 0m24.420s 0m22.725s 0m20.701s
user 0m23.930s 0m22.170s 0m20.180s
sys 0m0.070s 0m0.080s 0m0.140s
Size of the patched version is comparable (slightly larger or
smaller depending on compiler flags).
Manuel
|
|
The API for using partial writes, as described in my last message, sucked.
So here's a patch against my last patch that changes things so that
write_bunzip_data calls read_bunzip_data itself behind the scenes whenever
necessary. So usage is now just start_bunzip(), write_bunzip_data() until it
returns a negative number, and then the cleanup at the end of
uncompressStream.
It adds 32 bytes to the executable, but it should allow the caller (tar) to be
simplified enough to compensate. Total -Os stripped exe size now 6856 bytes.
Rob
P.S. I attached the whole C file so you don't have to keep incremental
patches straight if you don't want to. :)
P.S. In the version I'm banging on now, I've simplified the license to just
LGPL. I read the OSL a bit more closely and the patent termination clause
would have bit IBM in their counter-suit of SCO if the code in question had
been OSL instead of GPL, and I've decided I just don't want to beta-test
legal code right now.
|
