On 05/02/18 03:03, Stuart Henderson wrote:
On 2018/05/02 00:50, Brian Callahan wrote:
Hi ports --
On 01/05/18 19:19, Brian Callahan wrote:
Hi ports --
Attached is a new port, devel/libaio. libaio is a port of the DragonFly
BSD userland POSIX asynchronous I/O routines to OpenBSD.
When updating lang/flang earlier today, I realized that there are a
dozen patches that work around the fact that OpenBSD doesn't have an
aio implementation. Having to maintain a number of patches for flang
already, reducing that number is a great help.
It turns out that DragonFly BSD has a minimal but standard-compliant
userland implementation of aio. So I did a quick and dirty port of it.
flang is very happy with it.
According to POSIX, these routines belong in librt. I'm not opening
that can of worms. I named the library libaio. That way, you have to
specifically seek it out to use it. The good news is that a quick
perusal of the ports tree didn't turn up any port other than flang that
has patches that work around not having aio. At this rate, it'll be
maybe 2038 by the time another port needs the library anyway.
---
pkg/DESCR:
libaio is a port of the POSIX asynchronous I/O library from DragonFly
BSD to OpenBSD.
This version of AIO is aimed at standards compliance; it is not aimed at
either reasonability or performance. It merely wraps synchronous I/O
routines.
---
Builds and passes some rudimentary tests on both amd64 and armv7. Makes
flang happy on amd64.
OK?
~Brian
I'd still like to get this in. New tarball attached. This will very much
help keep flang updated.
If I understand correctly this is for posix AIO support - aio_read,
aio_write, aio_fsync etc, rather than emulating the functions in Linux's
libaio (wrapper for syscall-based implementation - io_setup, io_submit,
etc). If that's right, I think it would be better to pick a different
name.
Correct. To be clear, are you suggesting a different PKGNAME or a
different PKGNAME and library name?
Please either create a release in github and upload a tarball as an
asset (giving a stable tarball), or if you're going to stick with the
on-the-fly autogenerated one, use GH_* instead of manually setting
MASTER_SITES/WRKDIST/etc (and be prepared to cope if github updates
their software stack in a way which changes the file).
I'll just host it myself, save the headache.
~Brian
