Re: iozone compilation failure with uclibc due to aio
On 10/12/2012 18.27, Rich Felker wrote: On Mon, Dec 10, 2012 at 05:43:54PM +0530, Madhu koriginja wrote: Hi All, I am facing compilation issue with the iozone compilation failure with uclibc library. I am using the uclibc 0.9.32 version, gcc 4.5 linaro toolchain. The same code is compiling with the gcc 4.5 linaro toolchain and glibc 2.14. Please help me to resolve this issue. Please see the compilation error below: [...] arm-openwrt-linux-uclibcgnueabi-gcc -c -O3 -Dunix -Dlinux -DHAVE_ANSIC_C -DASYNC_IO \ -D_LARGEFILE64_SOURCE -Os -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -fhonour-copts -msoft-float libasync.c -o libasync.o libasync.c:98:17: fatal error: aio.h: No such file or directory compilation terminated. As far as I know, uClibc does not implemnt the AIO part of POSIX. Is there perhaps any way to make iozone use some fallback in place of AIO? It's not like POSIX AIO is a particularly well-designed API that anybody would actually WANT to use... If there's really no way around it, you could see if someone could help you getting AIO added to uClibc. Rich FYI, We (@ST) do use iozone on uClibc with the AIO support switched off w/o problems. So as Rich suggested, there is a way to use a fallback solution. I guess that not passing -DASYNC_IO should make the trick. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: iozone compilation failure with uclibc due to aio
On Mon, Dec 10, 2012 at 05:43:54PM +0530, Madhu koriginja wrote: Hi All, I am facing compilation issue with the iozone compilation failure with uclibc library. I am using the uclibc 0.9.32 version, gcc 4.5 linaro toolchain. The same code is compiling with the gcc 4.5 linaro toolchain and glibc 2.14. Please help me to resolve this issue. Please see the compilation error below: [...] arm-openwrt-linux-uclibcgnueabi-gcc -c -O3 -Dunix -Dlinux -DHAVE_ANSIC_C -DASYNC_IO \ -D_LARGEFILE64_SOURCE -Os -pipe -march=armv7-a -mtune=cortex-a9 -fno-caller-saves -fhonour-copts -msoft-float libasync.c -o libasync.o libasync.c:98:17: fatal error: aio.h: No such file or directory compilation terminated. As far as I know, uClibc does not implemnt the AIO part of POSIX. Is there perhaps any way to make iozone use some fallback in place of AIO? It's not like POSIX AIO is a particularly well-designed API that anybody would actually WANT to use... If there's really no way around it, you could see if someone could help you getting AIO added to uClibc. Rich ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: iozone compilation failure with uclibc due to aio
On Mon, Dec 10, 2012 at 09:56:38PM +0100, Laurent Bercot wrote: As far as I know, uClibc does not implemnt the AIO part of POSIX. Is there perhaps any way to make iozone use some fallback in place of AIO? It's not like POSIX AIO is a particularly well-designed API that anybody would actually WANT to use... Hello Rich, From a purely theoretical/academic point of view, as a software engineer, I'm interested in knowing the details of why you think AIO is badly designed. Not saying I disagree (I've never used that part of POSIX so I don't know it enough to have an opinion), I'd just like to hear your arguments about it. Perhaps my opinion is influenced by the ugliness and broken corner cases that arise trying to implement it in userspace on top of orginary POSIX IO functions and threads. See the glibc bug I just submitted, #14942: http://sourceware.org/bugzilla/show_bug.cgi?id=14942 In fairness, our implementation in musl is at present just as broken as glibc's and probably more broken. Still, I think there's a lot of ugliness inherent in the API. Some things that come to mind: 1. Having to submit your requests with a structure containing the arguments rather than with function arguments. It would be better if the arguments (like fd, offset, etc.) were actual function arguments and you got back an opaque handle for the request (rather than having internal stuff hidden in the non-opaque aiocb buffer). This can of course be fixed by wrapping the API, so it's not a huge issue. 2. Use of sigevent for completion-notification. SIGEV_THREAD has a lot of flaws that make it virtually impossible to use correctly, so you're stuck with signals, which involve nasty global state and aren't library-safe. This is more a complaint about sigevent's poor specification in general than about AIO in particular, but it's pretty much a show-stopper if you want asynchronous delivery of completion notification in a library; it certainly crosses the point at which it becomes easier, safer, AND cleaner to just roll your own async IO using threads. 3. Underspecified corner-cases, like whether there's any ordering between AIO requests on different file descriptors that refer to the same underlying open file description or even just the same underlying file (with a different open file description). If it's too off-topic for the list, we can take the discussion to private, but I believe other readers could be interested in it too. I don't think it's too off-topic. Certainly if this feature is to be added to uClibc, there should be an understanding of what's ugly about it and what makes it so difficult to get right. Rich ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
