[PATCH v3 00/48] Support for cut-down Linux syscalls

Markos Chandras markos.chandras at gmail.com
Wed Feb 6 16:20:24 UTC 2013


On 6 February 2013 16:03, Bernhard Reutner-Fischer
<rep.dot.nop at gmail.com> wrote:
> On 6 February 2013 14:02, Markos Chandras <markos.chandras at gmail.com> wrote:
>> On 6 February 2013 10:06, Will Newton <will.newton at gmail.com> wrote:
>>> On Tue, Feb 5, 2013 at 9:45 PM, Markos Chandras
>>> <markos.chandras at gmail.com> wrote:
>>>> On 5 February 2013 19:08, Bernhard Reutner-Fischer
>>>> <rep.dot.nop at gmail.com> wrote:
>>>>> On 23 January 2013 12:41, Markos Chandras <markos.chandras at gmail.com> wrote:
>>>>>> From: Markos Chandras <markos.chandras at imgtec.com>
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> This is the v3 of the patchset I sent on the 26th of November 2012[1].
>>>>>>
>>>>>> Changes since v2:
>>>>>>
>>>>>> - Base patches on the uClibc master branch
>>>>>> - Fix libc_hidden_def for faccessat when implementing the access syscall[2]
>>>>>> - Make vfork act as fork using the clone syscall[3]
>>>>>> - Fix #ifdef clause for the stat syscall[4]
>>>>>> - c6x is a new arch, so it does not need ARCH_HAS_DEPRECATED_SYSCALLS[5]
>>>>>> - Fix non-LFS compilation problems[6]
>>>>>> - Add new struct stat and struct statfs for new architectures so we can
>>>>>> pass them directly to syscalls and avoid conversion code[7]
>>>>>
>>>>> Looks pretty good, thanks. One thing though:
>>>>>
>>>>> I really don't like common-no-legacy.
>>>>> Can you propose a different way instread?
>>>>
>>>> Hi Bernhard,
>>>>
>>>> Thanks for taking time reviewing this patchset.
>>>>
>>>> How about:
>>>>
>>>> - common-new
>>>> - new-interfaces
>>>
>>> generic
>>> generic-syscalls
>>>
>>> generic wouldn't be entirely self-explanatory but would be short. ;-)
>>
>> I'd prefer generic-syscalls. 'generic' seems similar to 'common' so it
>> might be a bit confusing. Bernhard, are you ok with
>> "generic-syscalls"?
>
> I was thinking more in the direction of not adding that directory in
> the first place.
> If you look at
> for i in $(find libc/sysdeps/linux/common-no-legacy/ -type f);do
> i=$(basename $i);diff -duNp
> libc/sysdeps/linux/common{,-no-legacy}/bits/$i;done  | less
> then perhaps we can use the dirent stuff everywhere, the stat.h parts
> look dangerous (hope that nobody does interpret those long long as DI
> mode).
> Perhaps it is less ugly to just ifdef those few new hunks?
>
> Short of that (sorry did not look closely yet, perhaps you do that
> already anyway), i'd go for common-newsyscalls and put that include
> before the common for the arches that were switched already.
>
> Other ideas?
> Comments?

Well personally I believe that mixing old and new structures with
#if/defs is a bit messy and it will be hard to spot what fields belong
to the struct for a particular architecture. I think that keeping new
architectures separate from the existing ones, is a)more safe (as in,
you don't risk breaking existing code accidentally ), b) easier to add
or modify new interfaces (as more new architectures are added to
uClibc, it may be necessary to add new shared headers in the new
common-newsyscalls directory) in the future and c) easier to deprecate
the common/ directory if existing architectures ever migrate to
generic syscalls.

-- 
Regards,
Markos Chandras


More information about the uClibc mailing list