Including <sys/disk*.h> without getting ioctl(2) defines
John Baldwin
jhb at freebsd.org
Mon Sep 26 18:05:06 UTC 2016
On Monday, September 26, 2016 09:05:51 AM Marcel Moolenaar wrote:
> Background:
> In order for a select set of FreeBSD utilities to compile on non-FreeBSD (specifically macOS and Linux) as build tools, we need some portability tweaks.
>
> Problem:
> mkimg(1) includes disk partitioning headers like <sys/disklabel.h>, <sys/diskmbr.h> and <sys/diskpc98.h> and those headers themselves include <sys/ioccom.h> for ioctl(2) definitions. The <sys/ioccom.h> header does not typically exist on the host we’re being, causing build failures.
>
> Proposal:
> What I like is to be able to use FreeBSD’s headers, but not pull in FreeBSD-specifics like ioctl(2) definitions.
>
> Solutions:
> 1. Split off the definitions relating to the partitioning into a separate header (e.g. <sys/bsdlabel.h>) and keep the FreeBSD-centric definitions (e.g. for ioctl(2)) in the original header (e.g. <sys/disklabel.h>. The original header will include the new header so that there’s no change to applications that include the original header. Portable tools like mkimg can include the new split-off header to get just the structure definitions and defines.
I think this. It is similar to the 'fooreg.h' vs 'foovar.h' split in some
drivers with fooreg.h generally being a standalone, portable header and
foovar.h defining FreeBSD-specific structures (softc, etc.).
I'd even be inclined to use some kind of sensible namespace for the header
names like <disk/mbr.h>, <disk/pc98.h>, <disk/bsd.h>, <disk/gpt.h>, etc.
While you are at it, please have these split out headers avoid conflicting
names unlike diskmbr.h and diskpc98.h. (We can use compat #define's in
diskmbr.h and diskpc98.h if needed to provide API compat.)
--
John Baldwin
More information about the freebsd-arch
mailing list