Libuv: A plan to simplify porting libuv to new platforms

[bradking]

Thanks for libuv!

As requested in SUPPORTED_PLATFORMS.md I'm opening this issue to discuss plans for porting libuv to additional platforms. I'd like to use libuv in projects (e.g. CMake) that support some platforms that libuv does not currently support (e.g. Cygwin, HP-UX), even if not all libuv functionality can be made available. I'm primarily interested in making the poll and process abstractions available to more platforms.

So far I've submitted PRs #1239, #1240, and #1260 to factor out reusable parts from implementations on existing platforms. I plan to submit at least one more such PR (for no-fsevents) and then move on to the new platforms. I've got a working implementation of uv__io_poll based on pure POSIX poll(2). It enables use of libuv poll and process abstractions on POSIX-only platforms. With that I've got the basic functionality working on Cygwin.

[bnoordhuis]

Sounds reasonable to me. The plan is to return UV_ENOSYS for everything that isn't supported by the platform?

Can you go in more detail on the Cygwin port? We used to have one but I removed it in 7f8130a on account of being broken and unused. Even when it still compiled it never was really great due to its unholy union of UNIX and Windows quirks.

[bradking]

@bnoordhuis Cygwin is intended to be a POSIX abstraction layer implemented on top of Windows, and they discourage attempts to use Windows APIs directly. Therefore my approach is to implement everything in terms of unix APIs available on Cygwin, even if this means limited functionality. (This could be revisited by others later that want to try to add more functionality such as fsevents.)

The original cygwin.c you linked looks like more of a placeholder. I did look at it during my investigation. It has no uv__io_poll implementation. I've implemented uv__io_poll based on POSIX poll(2) which is available on Cygwin. That is the main hurdle, at least for the poll and process abstractions. The posix-only poll implementation will also be useful on other new platforms later. (I even hacked my local build to use it on Linux instead of epoll and it worked well other than for fsevents.)

I've also identified APIs available on Cygwin for implementing some of the other pieces (e.g. loadavg) that are also used on some other platforms. For those I'm first factoring reusable parts out so that cygwin.c does not need to duplicate them. Then we'll be able to have a new cygwin.c that is relatively small. Much of the Cygwin implementation will be shared with already-supported platforms.

[saghul]

@bradking I'm not opposed to having Cygwin, but I'll ask you the same question I asked IBM when they wanted to add AIX and zOS support: what kind of commitment can we expect with regards to maintenance?

[bradking]

@saghul since CMake 3.7 libuv is an optional dependency that is used in the cmake-server(7) implementation. My goal is to make libuv a hard dependency of CMake so that we can use its poll and process abstractions everywhere in our code (replacing some existing less-sophisticated implementations). That means we need to make libuv process and poll abstractions work everywhere CMake currently supports. CMake maintainers will then have a long-term interest in maintaining platforms in libuv that CMake needs but are not otherwise supported.

Currently Cygwin and HP-UX are missing, but other platforms may arise in the future. That's why I'm trying to implement as much as possible in terms of re-usable granular sources that one can pick-and-choose for each new platform. The pure-posix uv__io_poll implementation will be particularly helpful as a fallback on POSIX platforms that don't have a more specialized poll API available.

[bnoordhuis]

Fixed by 6c2fe3d...6216553.

[swingfield]

Hi @brad.king, I was curious if you were successful with libuv and hp-ux. I saw on the CMake side there were other, non-libuv issues with hp, and maybe you stopped with libuv because of the other blockers. Just thought I’d check as I’m interested in libuv on hp. Thanks for your work on that.

[bradking]

@swingfield we ended up dropping HP-UX support in CMake 3.10 for a number of reasons so we also dropped work on libuv for that. The groundwork laid here was still a big step toward HP-UX support in libuv though.

[michael-o]

@bradking CMake and HP-UX user here. We are currently porting approx. 1 000 000 LOC of C and Fortran from a custom build system to CMake 3.9 and HP aCC as well as f90. I already see room for improvement on the prebundled .cmake files from PREFIX/share. Maybe we can get it touch on CMake and libuv on HP-UX (via https://gitlab.kitware.com/cmake/cmake/issues/17137) ? I am not the best C programmer (not my primary focus), but I can get things done in time. We could maybe push 3.9.7 first and then continue on post 3.9?!

[bradking]

@michael-o thanks. I've started discussion over in the CMake issue. We can work over there for now.