[Bug 292889] [NEW PORT] net/ucx: Unified Communication X (UCX) framework

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292889

Robert Clausecker <fuz@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fuz@FreeBSD.org
         Resolution|Not Accepted                |---
             Status|Closed                      |Open

--- Comment #19 from Robert Clausecker <fuz@FreeBSD.org> ---
(In reply to Generic Rikka from comment #16)

Reopening.

Initial review of your patch set:

 - the brk() syscall may be going away in the future and is already not
available
   on some platforms
 - we do support eventfd() since FreeBSD 13, not sure why you patch it out
 - HOST_NAME_MAX can be determined through sysconf(_SC_HOST_NAME_MAX) or as
   _POSIX_HOST_NAME_MAX in <limits.h>.  Furthermore, you are defining polyfill
   for HOST_NAME_MAX in two different places, maybe this can be consolidated?
 - we also support netlink since FreeBSD 13, though I don't know if we support
   enough of it for the purpose of this program
 - This is suspect:

#if defined(HAVE_NETINET_IN_H) || defined(__FreeBSD__)
#if defined(HAVE_ARPA_INET_H) || defined(__FreeBSD__)

   consider fixing the configure test instead so it finds the header on FreeBSD
 - raw syscalls work on FreeBSD as they do on Linux, but you need to use
SYS_...
   instead of __NR_...  So e.g. syscall(SYS_munmap, ...) to call munmap().  I
do
   not know why the Linux code doesn't just call munmap() directly though.  Do
you
   know if it is correct to go through libc when the Linux code path takes
great
   care not to?
 - for your floating point stuff: note that FP byte order is independent of
host
   byte order and there are some platforms (e.g. MIPS) where it doesn't match.
   It may be safer to add a configure test here.
 - can you refactor the #ifdef cascade for include <ieee754.h> so that it
doesn't
   repeat the structure definitions?
 - the usage of bit fields in your definition of iphdr and ipv6hdr is suspect
and
   likely to break as different ABIs lay out bitfields in different manners.
   Have you tested this on all platforms we support, in particular on
   ppc/ppc64/ppc64le?

-- 
You are receiving this mail because:
You are the assignee for the bug.