Re: [PATCH 1/5] bb_socklen_t must be signed int

'bb_socklen_t *' __socketcall int getsockname(int, struct sockaddr *, socklen_t *); ^ On Friday, 24 April 2015, at 4:12 am, Matt Whitlock wrote: > BSD and POSIX specify socklen_t as int. Busybox should too, to avoid pointer > signedness warnings. >

Re: [PATCH] Bionic lacks transparent LFS migrations; provide a workaround

On Sunday, 3 May 2015, at 6:54 pm, Denys Vlasenko wrote: > On Sat, Apr 25, 2015 at 11:33 PM, Matt Whitlock > wrote: > > On Saturday, 25 April 2015, at 7:17 pm, Denys Vlasenko wrote: > >> Let me know how I can test this on a x86 machine. > > > > Bionic doesn't

Re: [PATCH 2/5] Bionic lacks mempcpy; enable existing workaround

d fdprintf() since API level 8. This is a direct replacement for dprintf(). (The Bionic header chides Glibc for choosing the name "dprintf".) * Bionic has supported ttyname_r(), getline(), and stpcpy() since API level 21. >From 3c0effb4ccab30fb59d70d5837ad46b50a196ef0 Mon Sep 17 00:00:00 2

Re: [PATCH] Bionic lacks transparent LFS migrations; provide a workaround

On Wednesday, 29 April 2015, at 1:26 am, Tanguy Pruvot wrote: > For this case i generally cast the param to the biggest possible type. > > printf("llu", (uint64_t) val); You probably shouldn't assume that uint64_t is the largest possible integer type. In particular, off_t is not guaranteed to be

Re: [PATCH] Bionic lacks transparent LFS migrations; provide a workaround

On Tuesday, 28 April 2015, at 3:55 pm, Matt Whitlock wrote: > I'll work on finishing the Large File Support in Bionic and adding support > for _FILE_OFFSET_BITS==64. The Bionic devs have already finished Large File Support, including support for _FILE_OFFSET_BITS==64, in the latest

Re: AW: [PATCH 5/5] Bionic lacks transparent LFS migrations; provide a workaround

On Tuesday, 28 April 2015, at 6:36 am, dietmar.schind...@manroland-web.com wrote: > Whose policy is that which caters to a certain compiler option's inept > warnings? "What are the goals of Busybox?" > (http://www.busybox.net/FAQ.html#goals) says: "We also want to have the > simplest and cleane

Re: [PATCH] Bionic lacks transparent LFS migrations; provide a workaround

On Tuesday, 28 April 2015, at 9:56 am, Rich Felker wrote: > What I do think is a bad idea is providing a hackish environment where > only some things work correctly with 64-bit off_t and others silently > fail or even misinterpret their arguments and blow up. If that can be > avoided and the ugline

Re: [PATCH] Bionic lacks transparent LFS migrations; provide a workaround

On Sunday, 26 April 2015, at 10:28 pm, Rich Felker wrote: > On Sat, Apr 25, 2015 at 04:06:23PM -0400, Matt Whitlock wrote: > > In short, Bionic has most of the syscall-level support introduced by > > _LARGEFILE64_SOURCE in Glibc, but they did not implement the > > transparent

Re: [PATCH] Bionic lacks transparent LFS migrations; provide a workaround

On Sunday, 26 April 2015, at 12:40 pm, Tanguy Pruvot wrote: > On which bionic version are you doing the tests ? 64bit arm/x86 devices are > recent. I'm building using a toolchain for Android API level 15 and testing on an ARM device running KitKat. ___

Re: [PATCH] Bionic lacks transparent LFS migrations; provide a workaround

On Saturday, 25 April 2015, at 7:17 pm, Denys Vlasenko wrote: > Let me know how I can test this on a x86 machine. Bionic doesn't really support vanilla Linux. The Android Developers' Bionic C Library Overview says: «Note that the x86 version is only meant to run on an x86 Android device. We mak

Re: [PATCH] Bionic lacks transparent LFS migrations; provide a workaround

On Saturday, 25 April 2015, at 11:38 am, Rich Felker wrote: > On Sat, Apr 25, 2015 at 04:53:33AM -0400, Matt Whitlock wrote: > > This solves some of the problems arising from Bionic's off_t being > > 32 bits wide despite _FILE_OFFSET_BITS==64. See BusyBox bug #6908. > >

[PATCH] Bionic lacks ttyname_r; provide a workaround

--- include/platform.h | 7 +++ libbb/platform.c | 17 + 2 files changed, 24 insertions(+) diff --git a/include/platform.h b/include/platform.h index 8914d4a..8896a6b 100644 --- a/include/platform.h +++ b/include/platform.h @@ -368,6 +368,7 @@ typedef unsigned smalluint; #

[PATCH] Bionic lacks transparent LFS migrations; provide a workaround

This solves some of the problems arising from Bionic's off_t being 32 bits wide despite _FILE_OFFSET_BITS==64. See BusyBox bug #6908. Note that this doesn't solve all such problems since Bionic lacks 64-bit variants of many standard I/O functions: open, creat, lockf, posix_fadvise, posix_falloc

Re: [PATCH] Bionic lacks transparent LFS migrations; provide a workaround

On Friday, 24 April 2015, at 5:42 pm, Matt Whitlock wrote: > This solves some of the problems arising from Bionic's off_t being 32 bits > wide despite _FILE_OFFSET_BITS==64. See BusyBox bug #6908. I found an issue with this patch: certain stdio functions were segfaulting. It was b

[PATCH] Bionic lacks setmntent, getmntent_r, endmntent; provide workarounds

Note: This commit subsumes a previous workaround (908d6b70, a0e17f7d) for the lack of getmntent_r in dietlibc. --- include/platform.h | 39 +++ libbb/platform.c| 47 +++ util-linux/mount.c | 12 uti

[PATCH 1/2] Bionic lacks ttyname_r; provide a workaround

--- include/platform.h | 7 +++ libbb/missing_syscalls.c | 17 + 2 files changed, 24 insertions(+) diff --git a/include/platform.h b/include/platform.h index 8914d4a..8896a6b 100644 --- a/include/platform.h +++ b/include/platform.h @@ -368,6 +368,7 @@ typedef unsigned s

[PATCH 2/2] Bionic lacks tcdrain; provide a workaround

--- libbb/missing_syscalls.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libbb/missing_syscalls.c b/libbb/missing_syscalls.c index c768f11..1e2507d 100644 --- a/libbb/missing_syscalls.c +++ b/libbb/missing_syscalls.c @@ -39,6 +39,11 @@ int pivot_root(const char *new_root, const char *

[PATCH] Bionic lacks transparent LFS migrations; provide a workaround

This solves some of the problems arising from Bionic's off_t being 32 bits wide despite _FILE_OFFSET_BITS==64. See BusyBox bug #6908. Note that this doesn't solve all such problems since Bionic lacks 64-bit variants of many standard I/O functions: open, creat, lockf, posix_fadvise, posix_falloc

Re: [PATCH 5/5] Bionic lacks transparent LFS migrations; provide a workaround

On Friday, 24 April 2015, at 4:12 am, Matt Whitlock wrote: > +#if defined(__BIONIC__) && _FILE_OFFSET_BITS == 64 The preprocessor needs to test whether _FILE_OFFSET_BITS is defined before using it in an expression. #if defined(__BIONIC__) && defined(_FILE_OFFSET_BITS) &&a

Re: [PATCH 1/2] Bionic lacks ttyname_r; provide a workaround

I think providing an alternative implementation of ttyname_r() in missing_syscalls.c won't work. Busybox cannot be statically linked when ttyname_r is defined in missing_syscalls.o: ld: error: /usr/local/arm-linux-androideabi/bin/../sysroot/usr/lib/libc.a(stubs.o): multiple definition of 'ttyn

[PATCH 1/2] Bionic lacks ttyname_r; provide a workaround

--- libbb/missing_syscalls.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/libbb/missing_syscalls.c b/libbb/missing_syscalls.c index dd430e3..e57c2de 100644 --- a/libbb/missing_syscalls.c +++ b/libbb/missing_syscalls.c @@ -39,4 +39,18 @@ int pivot_root(const char *new_root, c

[PATCH 2/2] Bionic lacks tcdrain; provide a workaround

--- libbb/missing_syscalls.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libbb/missing_syscalls.c b/libbb/missing_syscalls.c index e57c2de..0de3df9 100644 --- a/libbb/missing_syscalls.c +++ b/libbb/missing_syscalls.c @@ -40,6 +40,11 @@ int pivot_root(const char *new_root, const char *

Re: [PATCH 3/5] Bionic lacks ttyname_r; provide a workaround

On Friday, 24 April 2015, at 1:04 pm, walter harms wrote: > perhaps it is better to move the code to missing_syscalls.c ? > (this is a question) The reason I didn't put it there is that ttyname_r() is defined in Bionic, but it's a stub that prints out a diagnostic message at runtime and returns -

[PATCH 4/5] Bionic lacks tcdrain; provide a workaround

--- libbb/missing_syscalls.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libbb/missing_syscalls.c b/libbb/missing_syscalls.c index dd430e3..e3c1e92 100644 --- a/libbb/missing_syscalls.c +++ b/libbb/missing_syscalls.c @@ -39,4 +39,9 @@ int pivot_root(const char *new_root, const char *p

[PATCH 1/5] bb_socklen_t must be signed int

BSD and POSIX specify socklen_t as int. Busybox should too, to avoid pointer signedness warnings. --- include/libbb.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/libbb.h b/include/libbb.h index f0ac1f5..dc0acd8 100644 --- a/include/libbb.h +++ b/include/libbb.h @@

[PATCH 2/5] Bionic lacks mempcpy; enable existing workaround

--- include/platform.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/platform.h b/include/platform.h index df95945..8914d4a 100644 --- a/include/platform.h +++ b/include/platform.h @@ -482,6 +482,7 @@ typedef unsigned smalluint; # undef HAVE_DPRINTF # undef HAVE_GETLINE # undef HA

[PATCH 3/5] Bionic lacks ttyname_r; provide a workaround

--- include/platform.h| 2 ++ libbb/xfuncs_printf.c | 10 ++ 2 files changed, 12 insertions(+) diff --git a/include/platform.h b/include/platform.h index 8914d4a..9893536 100644 --- a/include/platform.h +++ b/include/platform.h @@ -369,6 +369,7 @@ typedef unsigned smalluint; #define

[PATCH 5/5] Bionic lacks transparent LFS migrations; provide a workaround

This solves some of the problems arising from Bionic's off_t being 32 bits wide despite _FILE_OFFSET_BITS==64. See BusyBox bug #6908. Note that this doesn't solve all such problems since Bionic lacks 64-bit variants of many standard I/O functions: open, creat, lockf, posix_fadvise, posix_falloc

Re: Anyone using udhcpc6

On 6-May-2014, at 3:19 pm, "Harshad Prabhu (hprabhu)" wrote: > Let me know if anyone has added (any patches) / using udhcpc6 support in > busybox. I *would* be using udhcpc6 if it were working. I've tried, and I just can't make it recognize the DHCPv6 response from Comcast's CMTS. I'm using Di

Re: udhcpc6 and Prefix Delegation

On Friday, 28 March 2014, at 3:54 pm, Julien Laffaye wrote: > Well, with udhcpc6, it keeps sending discovers and never get a response. > wide-dhcpv6 works on the same link. > > (I should have started by specifying that in my first email) > > I guess I will capture the traffic with both dhcp clien

Re: /proc//cmdline and udhcpcd

On Wednesday, 26 March 2014, at 1:38 pm, Cristian Ionescu-Idbohrn wrote: > On Wed, 26 Mar 2014, Matt Whitlock wrote: > > Tons of programs modify their argv arrays. > > Alright, you know better. It's common for programs that accept sensitive information (such as password

Re: /proc//cmdline and udhcpcd

On Wednesday, 26 March 2014, at 1:19 pm, Cristian Ionescu-Idbohrn wrote: > But really, this is not an `init' question, as I see it. It's about > keeping the original/unmodified program arguments in > /proc//cmdline. > > I know of no other program doing such sort of thing, although I think > I und

Re: /proc//cmdline and udhcpcd

On Wednesday, 26 March 2014, at 12:46 pm, Cristian Ionescu-Idbohrn wrote: > Is it possible to restrain from modifying the arguments for the > command line? The problem is that the process watcher used here is > dependant on having the original/unmodified /proc//cmdline. If > the watched process d

Re: /proc//cmdline and udhcpcd

On Tuesday, 25 March 2014, at 10:52 pm, Cristian Ionescu-Idbohrn wrote: > I find out that using that option: > > -x hostname:foo > ^ > > shows up in /proc//cmdline as: > > -x hostname foo > ^ /proc//cmdline reflects any changes that the process has

Re: [PATCH] add discard option -d to swapon

On Monday, 24 March 2014, at 12:06 am, Tito wrote: > On Sunday 23 March 2014 23:09:59 you wrote: > > This is still going to create a "hell" when adding the discard flag. > > Consider what will happen in the enum: if DISCARD is enabled but PRI is > > disabled, then OPT_d will be (1 << 1), but if b

Re: [PATCH] add discard option -d to swapon

On Sunday, 23 March 2014, at 8:29 pm, Tito wrote: > On Sunday 23 March 2014 00:33:04 Matt Whitlock wrote: > > Attached are a series of three patches affecting swaponoff. > > Hi, > attached you will find a alternative patch to your patches #1 and #2 that > includes your fix

[PATCH] add discard option -d to swapon

3 adds a -d option to swapon, which sets SWAP_FLAG_DISCARD and potentially SWAP_FLAG_DISCARD_ONCE or SWAP_FLAG_DISCARD_PAGES if a policy is given. The patch also adds support for the 'discard' option in swap entries in /etc/fstab.>From 1509caf8e5088ed92ae6c7ab54d65785df570351 Mon Sep 17