Opened 3 years ago

Closed 8 months ago

#12617 closed bug (fixed)

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

Reported by: TwoFx Owned by: nobody
Priority: normal Milestone: R1
Component: Build System Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by diver)

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.

Attachments (1)

bsd.patch (350.4 KB) - added by TwoFx 3 years ago.

Download all attachments as: .zip

Change History (11)

Changed 3 years ago by TwoFx

Attachment: bsd.patch added

comment:1 Changed 3 years ago by diver

Component: - GeneralBuild System
Description: modified (diff)
Milestone: UnscheduledR1
Owner: changed from nobody to korli
Status: newassigned

comment:2 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by 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 structs, 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.

Last edited 3 years ago by TwoFx (previous) (diff)

comment:4 Changed 3 years ago by 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?

comment:5 in reply to:  4 Changed 3 years ago by 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.

comment:6 Changed 3 years ago by 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).

comment:7 Changed 3 years ago by korli

Owner: changed from korli to nobody

comment:8 Changed 19 months ago by 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.

comment:9 Changed 19 months ago by waddlesplash

Added sys/queue.h to libbsd in hrev51678.

comment:10 Changed 8 months ago by waddlesplash

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.