Merge all instances of BSD headers into one place (WIP/Help requested)

[TwoFx]

BSD library headers exist in several places, most notably /headers/compatibility/bsd/ and /src/libs/compat/freebsd_network/compat. The latter is a significantly more complete version, but it is unavailable to normal apps outside the tree. Making these headers available is crucial for being able to port applications which natively run on BSD to Haiku.

I have attached a WIP of merging the sys/ and machine/ folders of compatibility and freebsd_network to compatibility, where they would be available to all apps which want to use them.

As you can see, this change is quite involved. In particular, the freebsd_network headers will depend on the compatibility/bsd headers, which means that all instances in the tree that use the freebsd_network headers need to have their Jamfile modified. I did that for a handful of instances where this comes up, but before I continued doing this change, I wanted to ask for comments whether this change is desirable in general.

[korli]

We have implemented a few BSD specific headers to ease porting, they reside in headers/compatibility/bsd, src/libs/bsd eventually src/system/libroot/posix. The headers and source files in freebsd compat layer are from FreeBSD itself for the most part, are subject to change in sync with the drivers which need this layer. These are mostly driver, network, kernel related.

This ticket as is makes no sense, you can't just make headers available without actually implementing what they describe. Furthermore you should be more specific about the software you hope to port. At the moment, I've no idea of what they could be. Providing a compatibility package for freebsd userland API could also reside at Haikuports.

[TwoFx]

The software I am porting that this ticked originated from is ​elftoolchain. You are right that the change as put in the patch provided is in many ways incomplete (and some of the files moved probably should stay in their original location). However, many of the headers are header-only, i.e. they consist of struct definitions, macros, and inline functions, so no additional functionality has to be provided by libbsd.so. The entirety of the headers required by elftoolchain (as far as I can tell) fall into that category. Those headers include sys/queue.h and sys/endian.h, which I would consider useful in a wide range of userland applications, which is why they, IMHO, should be available to all userland applications. Those in turn include more headers, and so forth, which is how the idea of just merging the two altogether came up in the first place.

[pulkomandy]

+1 to sys/queue.h, which should really be part of the C standard :)

However, your patch moves a lot more things to the public headers, which shouldn't be there. All the "bus" and other low-level things are for kernel-side of FreeBSD, not public APIs, and we don't want to expose those as public headers.

So, I suggest moving only what you really need (queue.h, maybe ar.h) to the public headers.

I have a doubt about ar.h: are we using the same format as FreeBSD for ar archives? Or are we using some gnu-extended one?

[TwoFx]

Replying to pulkomandy:

However, your patch moves a lot more things to the public headers, which shouldn't be there. All the "bus" and other low-level things are for kernel-side of FreeBSD, not public APIs, and we don't want to expose those as public headers.

So, I suggest moving only what you really need (queue.h, maybe ar.h) to the public headers.

Agreed, I will scrap the last commit of the patch and redo it in a more selective way.

I have a doubt about ar.h: are we using the same format as FreeBSD for ar archives? Or are we using some gnu-extended one?

I am no expert on the AR format, but here are my observations: Right now, Haiku does not supply ar.h at all. The ar.h which is installed on my Debian machine and is part of a reasonably modern version of the GNU C library does not define anything which the FreeBSD version which I included in the patch does not also define. To me, this suggests that GNU does not extend the AR format in a way which would concern this header. If you want to be safe, pulling the header locally into the libelftoolchain patches rather than making it available publicly might be an option.

[pulkomandy]

I think it's easy to test if elftoolchain tools work properly, if they do it means the header is compatible with our ar files (you can try this with any static library .a file).

[waddlesplash]

Looks like patches 1 and 2 can/should be applied pretty easily and patch 3 is the debatable one here. I can take a look at this.

[waddlesplash]

Added sys/queue.h to libbsd in hrev51678.

[waddlesplash]

As korli noted above, mass-moving the freebsd_network headers to make them "available" is not what we want here. Certain things do make sense, like sys/queue.h, but we can deal with these as they come up.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone