[lkml]   [2008]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: microblaze syscall list
Arnd Bergmann wrote:

>> As a first pass at assessing the C library impact on a completely
>> renovated syscall list, I took Michal's proposed new unistd.h and used
>> it to grep over both the uClibc implementation that (almost) every
>> existing microblaze user uses (!MMU), plus the glibc (cough cough)
>> implementation that is our default with the emerging MMU support.
>> To test the implementation / reference of a syscall number, I grepped
>> the entire source trees for
>> __NR_xxx
>> or
>> _system[0-9](.*xxxx (stripped leading __NR_X)
>> to try and find any mention at all of a particular syscall in that C
>> library implementation.
> I think for glibc, you also need to look for INLINE_SYSCALL and
> INTERNAL_SYSCALL, possibly more.

OK, new list at the end of this email.

> However, note that many of the syscall numbers that are referenced
> by glibc are not _required_ by it, because it already contains
> alternative implementations.


>> The results are interesting, and verbose. In fact, the lists are so
>> long I'm almost certain I've missed some other obscure way that uClibc
>> or glibc can access a __NR_ macro. Please let me know if this is the case.
>> Certainly there are many implemented in neither, such as as splice and
>> friends.
>> Also interesting is e.g. openat() - it is implemented/referenced by
>> neither! So, surely it would be premature to phase out open() in favour
>> of openat() when the latter is not in any viable MicroBlaze C library yet.
> openat was added in glibc-2.4 as a syscall, see

OK. Our glibc patches are against 2.3.3. I realise it's not the most
recent, but it's the best we've got for now.

> What is not yet there is code to implement open() using openat() in the
> absense of __NR_open.

>> I guess we need some help to find the other critical ones.
> I think your approach is flawed, it doesn't help at all to look at what
> your libc currently does if you already think that you will need to change
> the libc code.

I can't help but feel we've got our wires crossed here.

If, for example, neither C library has code to use openat in the absence
of __NR_open, then surely it is premature to remove __NR_open from any
arch, microblaze included?

> A more relevant question is what changes should be done in glibc for this
> in the first place, and I would like to hear Ulis opinion on that.

This is all very reasonable, but it's not clear why broad changes in
glibc would be part of MicroBlaze's critical path into
There are already N arch's in the kernel using mixture of obsolete and
new API's, I don't see the problem with MicroBlaze making it N+1.

> Uli: The question at hand is what syscalls a new linux architecture


> This list is possibly more useful as a "what's wrong with uClibc" list.
> Most of these syscalls were added recently and should be added in uClibc
> eventually, at least the subset of them that is also provided by glibc.

I'm not interested in a glibc vs uClibc debate. For deeply embedded
systems that MicroBlaze targets, uClibc's smaller footprint makes a lot
of sense.

The installed base of uClibc vs glibc for MicroBlaze is probably 10000:1
or more in uClibc's favour due to our history being entirely !MMU until
2008. I don't expect that to change much once we get the MMU and
functionality into our uClibc port.

> You are obviously missing the INLINE_SYSCALL and INTERNAL_SYSCALL here.
> I do think that having this list (in a correct form) is useful for the
> discussion, so it would be nice if you could do it again, including those.

OK, new list below (note glibc 2.3.3) - it's still pretty long but 32
fewer than the last iteration.

FYI here's the search expression ($syscall is the __NR_ macro)

egrep -R \

Not implemented/referenced in glibc

 \ /
  Last update: 2008-05-05 03:13    [W:0.067 / U:0.020 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site