Date: Mon, 26 Sep 2016 09:05:51 -0700 From: Marcel Moolenaar <marcel@xcllnt.net> To: "=?utf-8?Q?freebsd-arch=40freebsd.org?=" <freebsd-arch@freebsd.org> Subject: Including <sys/disk*.h> without getting ioctl(2) defines Message-ID: <etPan.57e9475f.18472693.e1fd@xcllnt.net>
next in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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.
2. Expect portable utilities to define a pre-processor macro (e.g. PORTABLE_DEFINITIONS_ONLY) and make FreeBSD-specific definitions conditional upon the *absence* of the preprocessor macro.
3. (Ab)use _POSIX_SOURCE to achieve the same as point 2.
4. Get rid of the utilities that still use the ioctl(2) interface and fix ports that do the same.
5. Others?
Notes:
1. Attached a hack to allow mkimg(1) to use FreeBSD’s headers for partitioning schemes. It shows what exactly the problem is without suggesting a solution. It’s a minimal change for a reason and not to be discussed as if it was a solution.
2. mkimg(1) is one example. Other utilities include makefs, mtree, etc. Please consider an approach that serves as a good precedence for other utilities if and when a similar situation is encountered.
[-- Attachment #2 --]
diff --git a/sys/sys/disklabel.h b/sys/sys/disklabel.h
index 42c757a..4ad10fb 100644
--- a/sys/sys/disklabel.h
+++ b/sys/sys/disklabel.h
@@ -36,7 +36,6 @@
#ifndef _KERNEL
#include <sys/types.h>
#endif
-#include <sys/ioccom.h>
/*
* Disk description table, see disktab(5)
diff --git a/sys/sys/diskmbr.h b/sys/sys/diskmbr.h
index 5f49eb9..cf5647d 100644
--- a/sys/sys/diskmbr.h
+++ b/sys/sys/diskmbr.h
@@ -33,8 +33,6 @@
#ifndef _SYS_DISKMBR_H_
#define _SYS_DISKMBR_H_
-#include <sys/ioccom.h>
-
#define DOSBBSECTOR 0 /* DOS boot block relative sector number */
#define DOSDSNOFF 440 /* WinNT/2K/XP Drive Serial Number offset */
#define DOSPARTOFF 446
@@ -86,6 +84,4 @@ void dos_partition_enc(void *pp, struct dos_partition *d);
#define DPSECT(s) ((s) & 0x3f) /* isolate relevant bits of sector */
#define DPCYL(c, s) ((c) + (((s) & 0xc0)<<2)) /* and those that are cylinder */
-#define DIOCSMBR _IOW('M', 129, u_char[512])
-
#endif /* !_SYS_DISKMBR_H_ */
diff --git a/sys/sys/diskpc98.h b/sys/sys/diskpc98.h
index aa0bb0a..bc70999 100644
--- a/sys/sys/diskpc98.h
+++ b/sys/sys/diskpc98.h
@@ -33,8 +33,6 @@
#ifndef _SYS_DISKPC98_H_
#define _SYS_DISKPC98_H_
-#include <sys/ioccom.h>
-
#define PC98_BBSECTOR 1 /* DOS boot block relative sector number */
#define PC98_PARTOFF 0
#define PC98_PARTSIZE 32
@@ -77,6 +75,4 @@ CTASSERT(sizeof (struct pc98_partition) == PC98_PARTSIZE);
void pc98_partition_dec(void const *pp, struct pc98_partition *d);
void pc98_partition_enc(void *pp, struct pc98_partition *d);
-#define DIOCSPC98 _IOW('M', 129, u_char[8192])
-
#endif /* !_SYS_DISKPC98_H_ */
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?etPan.57e9475f.18472693.e1fd>