[Toybox] [Aboriginal] aboriginal linux

[Rob Landley]

Redirected to the toybox list, where I have a pending message to reply
to on this topic already...

On 09/27/14 20:43, James McMechan wrote:
> just a couple comments
> 
> I would think that 
> 
> #define faccessat(A, B, C, D) faccessat(A, B, C, 0)
> 
> might better be as 
> 
> #define faccessat(A, B, C, D) faccessat(A, B, C, D & ( ~AT_SYMLINK_NOFOLLOW) )
>
> so that when something actually wants to use AT_EACCESS it will either get passed through or fail noisily.

Ideally we'd want to fix it properly upstream. In theory there's a
thread on the toybox list about that. I've been head down trying to get
a toybox release out this weekend (as I have the past 3 weekends, sigh),
so I'm a bit behind on email...

But right now faccessat() has no interesting flags, and in fact there's
no way for the system call to receive flags. I'm awaiting the kernel
guys to define a new system call that can receive flags, and a libc
upgrade to start using the new system call, and in the meantime I'm
doing the right thing (getting the same behavior as 0 on everything
except the gratuitously broken musl, and then automatically getting the
right behavior when the new system call arrives and libc starts using it
without having to remember to go back and change my code.)

And yes, the kernel guys do this sort of thing all the time:

http://lwn.net/Articles/585415/

> Long ago I developed a strong dislike for the library emulating features when GNU's glibc emulated aio by helpfully making my program multi-threaded and hijacking signals.

You think that's bad, dalias decided that implementing AT_EACCESS
required spawning a new process for every system call. (setfsuid()
exists, thanks to the samba guys, but apparently doesn't apply here. No
idea why.)

> I found your workaround of multiple -e clauses simpler and easier to read, than the alternation "\|" but back in 1986 when I was learning about grep maybe it was more primitive, but even now I like the simple answer better.

I didn't follow that bit. Toybox grep implements multiple -e clauses by
gluing them together with \| (which means that unbalanced parentheses
can have unexpected results, but doing that is an error _anyway_, so...)

> Jim McMechan

Rob

> ----------------------------------------
>> Date: Fri, 26 Sep 2014 20:26:05 -0500
>> From: rob at landley.net
>> To: stephen.n.turner at gmail.com
>> CC: Aboriginal at lists.landley.net
>> Subject: Re: [Aboriginal] aboriginal linux
>>
>> On 09/26/14 19:40, stephen Turner wrote:
>>>> The fix I coded up that evening boiled down to adding a stanza to
>>>> portability.h something like:
>>>>
>>>> #ifdef __MUSL__
>>>> // Long explanation of why musl is wrong.
>>>> #include <someheader.h>
>>>> #define faccessat(A, B, C, D) faccessat(A, B, C, 0)
>>>> #endif
>>>>
>>>> And then doing an echo "#define __MUSL__" to the end of features.h
>>>> during the musl build in aboriginal. But I didn't check it in, and
>>>
>>> I was using the static compiled binary from your site when I had this
>>> issue. Are you sure its musl lib? Is that what your building toybox
>>> against currently?
>>
>> Yup, the 0.4.9 binaries were compiled against musl. (I did test them
>> against musl, but obviously not thoroughly enough.)
>>
>> Next release should have it fixed.
>>
>>>>> Is the regex file the patch for grep -e?
>>>>
>>>> Yes. Internally grep is doing "REGEX1\|REGEX2\|REGEX3" to glue 'em
>>>> together, and tre only supported | in extended regex mode, not as an
>>>> escape in normal regex. So I fixed that.
>>>>
>>>> (I'll think about writing entirely posix compliant toybox code when
>>>> somebody can tell me how to implement ps or losetup that way. Until
>>>> then, linux has man pages that say we can do things, and I believe
>>>> them.)
>>>>
>>>> Rob
>>>
>>> Should I be applying this patch to gcc, musl, or toybox?
>>
>> The regex patch is against musl.
>>
>> Rob
>>
>> _______________________________________________
>> Aboriginal mailing list
>> Aboriginal at lists.landley.net
>> http://lists.landley.net/listinfo.cgi/aboriginal-landley.net
>  		 	   		  
>