Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers (v2)

2011-11-27 Thread Robert Millan
Hi Bruce,

2011/11/27 Bruce Evans b...@optusnet.com.au:
 % Index: sys/cam/scsi/scsi_low.h
 % ===
 % --- sys/cam/scsi/scsi_low.h   (revision 227956)
 % +++ sys/cam/scsi/scsi_low.h   (working copy)
 % @@ -53,10 +53,10 @@
 %  #define      SCSI_LOW_INTERFACE_XS
 %  #endif       /* __NetBSD__ */
 % % -#ifdef     __FreeBSD__
 % +#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 %  #define      SCSI_LOW_INTERFACE_CAM
 %  #define      CAM
 % -#endif       /* __FreeBSD__ */
 % +#endif /* __FreeBSD__ || __FreeBSD_kernel__ */

 It still has the whitespace-after tab style change for cam.

My initial patch didn't have it.  Precisely I thought that you
requested this in your first mail.  Did I missunderstand?

 % Index: sys/dev/firewire/firewirereg.h
 % ===
 % --- sys/dev/firewire/firewirereg.h    (revision 227956)
 % +++ sys/dev/firewire/firewirereg.h    (working copy)
 % @@ -75,7 +75,8 @@
 %  };
 % %  struct firewire_softc {
 % -#if defined(__FreeBSD__)  __FreeBSD_version = 50
 % +#if (defined(__FreeBSD__) || defined(__FreeBSD_kernel__))  \
 % +    __FreeBSD_version = 50
 %       struct cdev *dev;
 %  #endif
 %       struct firewire_comm *fc;

 Here is a pre-existing problem that you didn't fix on a line that you
 changed.

Yes.  I didn't say I would fix all pre-existing problems in lines that
need to be modified.  In some cases I did, and in some cases I opted
to preserve the status quo.

 __FreeBSD_version it is impossible to determine if the data structure
 has new fields like the cdev in it.  sys/param.h is a prerequisite
 for almost all kernel .c files, so this prerequisite should be satisfied
 automatically for them,

Earlier you asked not to include sys/param.h.  If sys/param.h is a
prerequisite, why not just include it then?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers (v2)

2011-11-26 Thread Robert Millan
On Fri, Nov 25, 2011 at 11:16:15AM -0700, Warner Losh wrote:
 Hey Bruce,
 
 These sound like good suggestions, but I'd hoped to actually go through all 
 these files with a fine-toothed comb to see which ones were still relevant.  
 You've found a bunch of good areas to clean up, but I'd like to humbly 
 suggest they be done in a follow-on commit.

Hi,

I'm sending a new patch.  Thanks Bruce for your input.  TTBOMK this corrects
all the problems you spotted that were introduced by my patch.  It doesn't
fix pre-existing problems in the files however, except in cases where I had
to modify that line anyway.

I think it's a good compromise between my initial patch and an exhaustive
cleanup of those headers (which I'm probably not the most indicate for).

-- 
Robert Millan
Index: sys/cam/scsi/scsi_low.h
===
--- sys/cam/scsi/scsi_low.h	(revision 227956)
+++ sys/cam/scsi/scsi_low.h	(working copy)
@@ -53,10 +53,10 @@
 #define	SCSI_LOW_INTERFACE_XS
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #define	SCSI_LOW_INTERFACE_CAM
 #define	CAM
-#endif	/* __FreeBSD__ */
+#endif /* __FreeBSD__ || __FreeBSD_kernel__ */
 
 / includes ***/
 #ifdef	__NetBSD__
@@ -64,7 +64,7 @@
 #include dev/isa/ccbque.h
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #include sys/device_port.h
 #include sys/kdb.h
 #include cam/cam.h
@@ -75,7 +75,7 @@
 
 #include cam/scsi/scsi_dvcfg.h
 #include i386/isa/ccbque.h
-#endif	/* __FreeBSD__ */
+#endif /* __FreeBSD__ || __FreeBSD_kernel__ */
 
 / functions macro /
 #ifdef	__NetBSD__
@@ -85,13 +85,13 @@
 #define	SCSI_LOW_BZERO(pt, size)	memset((pt), 0, (size))
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #undef	MSG_IDENTIFY
 #define	SCSI_LOW_DEBUGGER(dev)	kdb_enter(KDB_WHY_CAM, dev)
 #define	SCSI_LOW_DELAY(mu)	DELAY((mu))
 #define	SCSI_LOW_SPLSCSI	splcam
 #define	SCSI_LOW_BZERO(pt, size)	bzero((pt), (size))
-#endif	/* __FreeBSD__ */
+#endif /* __FreeBSD__ || __FreeBSD_kernel__ */
 
 / os depend interface structures **/
 #ifdef	__NetBSD__
@@ -111,7 +111,7 @@
 };
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 typedef	struct scsi_sense_data scsi_low_osdep_sense_data_t;
 
 struct scsi_low_osdep_interface {
@@ -134,7 +134,7 @@
 
 struct scsi_low_osdep_lun_interface {
 };
-#endif	/* __FreeBSD__ */
+#endif /* __FreeBSD__ || __FreeBSD_kernel__ */
 
 / os depend interface functions */
 struct slccb;
Index: sys/cam/scsi/scsi_low_pisa.h
===
--- sys/cam/scsi/scsi_low_pisa.h	(revision 227956)
+++ sys/cam/scsi/scsi_low_pisa.h	(working copy)
@@ -40,8 +40,8 @@
 int scsi_low_notify_pisa(pisa_device_handle_t, pisa_event_t);
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 int scsi_low_activate_pisa(struct scsi_low_softc *, int);
 int scsi_low_deactivate_pisa(struct scsi_low_softc *);
-#endif	/* __FreeBSD__ */
+#endif /* __FreeBSD__ || __FreeBSD_kernel__ */
 #endif	/* !_SCSI_LOW_PISA_H_ */
Index: sys/contrib/altq/altq/altq_var.h
===
--- sys/contrib/altq/altq/altq_var.h	(revision 227956)
+++ sys/contrib/altq/altq/altq_var.h	(working copy)
@@ -201,7 +201,7 @@
 #define	CALLOUT_STOP(c)		untimeout((c)-c_func,(c)-c_arg)
 #define	CALLOUT_INITIALIZER	{ NULL, NULL }
 #endif
-#if !defined(__FreeBSD__)
+#if !defined(__FreeBSD__)  !defined(__FreeBSD_kernel__)
 typedef void (timeout_t)(void *);
 #endif
 
Index: sys/contrib/altq/altq/if_altq.h
===
--- sys/contrib/altq/altq/if_altq.h	(revision 227956)
+++ sys/contrib/altq/altq/if_altq.h	(working copy)
@@ -29,7 +29,7 @@
 #ifndef _ALTQ_IF_ALTQ_H_
 #define	_ALTQ_IF_ALTQ_H_
 
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #include sys/lock.h		/* XXX */
 #include sys/mutex.h		/* XXX */
 #include sys/event.h		/* XXX */
@@ -51,7 +51,7 @@
 	int	ifq_len;
 	int	ifq_maxlen;
 	int	ifq_drops;
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 	struct	mtx ifq_mtx;
 #endif
 
Index: sys/contrib/pf/net/if_pflog.h
===
--- sys/contrib/pf/net/if_pflog.h	(revision 227956)
+++ sys/contrib/pf/net/if_pflog.h	(working copy)
@@ -30,7 +30,7 @@
 #define	PFLOGIFS_MAX	16
 
 struct pflog_softc {
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 	struct ifnet		*sc_ifp;	/* the interface pointer */
 #else
 	struct ifnet		sc_if;		/* the interface */
@@ -74,7 +74,7 @@
 #define	OLD_PFLOG_HDRLEN	sizeof(struct old_pfloghdr)
 
 #ifdef

Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers (v2)

2011-11-24 Thread Robert Millan
Hi Bruce,

2011/11/24 Bruce Evans b...@optusnet.com.au:
 Now it adds lots of namespace pollution (all of sys/param.h, including
 all of its namespace pollution), just to get 1 new symbol defined.

Well, my initial patch (see mail with same subject modulo v2) didn't
have this problem.  Now that __FreeBSD_kernel__ is defined, many
#ifdefs can be simplified, but maybe it's not desireable for all of
them.  At least not until we can rely on the compiler to define this
macro.

So in this particular case maybe it's better to use the other approach?

See attachment.
diff -ur sys.old/cam/scsi/scsi_low.h sys/cam/scsi/scsi_low.h
--- sys.old/cam/scsi/scsi_low.h	2007-12-25 18:52:02.0 +0100
+++ sys/cam/scsi/scsi_low.h	2011-11-13 14:12:41.121908380 +0100
@@ -53,7 +53,7 @@
 #define	SCSI_LOW_INTERFACE_XS
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #define	SCSI_LOW_INTERFACE_CAM
 #define	CAM
 #endif	/* __FreeBSD__ */
@@ -64,7 +64,7 @@
 #include dev/isa/ccbque.h
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #include sys/device_port.h
 #include sys/kdb.h
 #include cam/cam.h
@@ -85,7 +85,7 @@
 #define	SCSI_LOW_BZERO(pt, size)	memset((pt), 0, (size))
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #undef	MSG_IDENTIFY
 #define	SCSI_LOW_DEBUGGER(dev)	kdb_enter(KDB_WHY_CAM, dev)
 #define	SCSI_LOW_DELAY(mu)	DELAY((mu))
@@ -111,7 +111,7 @@
 };
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 typedef	struct scsi_sense_data scsi_low_osdep_sense_data_t;
 
 struct scsi_low_osdep_interface {
diff -ur sys.old/cam/scsi/scsi_low_pisa.h sys/cam/scsi/scsi_low_pisa.h
--- sys.old/cam/scsi/scsi_low_pisa.h	2005-01-05 23:34:37.0 +0100
+++ sys/cam/scsi/scsi_low_pisa.h	2011-11-13 14:12:41.121908380 +0100
@@ -40,7 +40,7 @@
 int scsi_low_notify_pisa(pisa_device_handle_t, pisa_event_t);
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 int scsi_low_activate_pisa(struct scsi_low_softc *, int);
 int scsi_low_deactivate_pisa(struct scsi_low_softc *);
 #endif	/* __FreeBSD__ */
diff -ur sys.old/contrib/altq/altq/altq_var.h sys/contrib/altq/altq/altq_var.h
--- sys.old/contrib/altq/altq/altq_var.h	2011-03-10 19:49:15.0 +0100
+++ sys/contrib/altq/altq/altq_var.h	2011-11-13 14:12:41.118907341 +0100
@@ -201,7 +201,7 @@
 #define	CALLOUT_STOP(c)		untimeout((c)-c_func,(c)-c_arg)
 #define	CALLOUT_INITIALIZER	{ NULL, NULL }
 #endif
-#if !defined(__FreeBSD__)
+#if !defined(__FreeBSD__)  !defined(__FreeBSD_kernel__)
 typedef void (timeout_t)(void *);
 #endif
 
diff -ur sys.old/contrib/altq/altq/if_altq.h sys/contrib/altq/altq/if_altq.h
--- sys.old/contrib/altq/altq/if_altq.h	2011-03-10 19:49:15.0 +0100
+++ sys/contrib/altq/altq/if_altq.h	2011-11-13 14:12:41.119907128 +0100
@@ -29,7 +29,7 @@
 #ifndef _ALTQ_IF_ALTQ_H_
 #define	_ALTQ_IF_ALTQ_H_
 
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #include sys/lock.h		/* XXX */
 #include sys/mutex.h		/* XXX */
 #include sys/event.h		/* XXX */
@@ -51,7 +51,7 @@
 	int	ifq_len;
 	int	ifq_maxlen;
 	int	ifq_drops;
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 	struct	mtx ifq_mtx;
 #endif
 
diff -ur sys.old/contrib/pf/net/if_pflog.h sys/contrib/pf/net/if_pflog.h
--- sys.old/contrib/pf/net/if_pflog.h	2011-06-28 13:57:25.0 +0200
+++ sys/contrib/pf/net/if_pflog.h	2011-11-13 14:12:41.130906469 +0100
@@ -30,7 +30,7 @@
 #define	PFLOGIFS_MAX	16
 
 struct pflog_softc {
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 	struct ifnet		*sc_ifp;	/* the interface pointer */
 #else
 	struct ifnet		sc_if;		/* the interface */
@@ -74,7 +74,7 @@
 #define	OLD_PFLOG_HDRLEN	sizeof(struct old_pfloghdr)
 
 #ifdef _KERNEL
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 struct pf_rule;
 struct pf_ruleset;
 struct pfi_kif;
diff -ur sys.old/contrib/pf/net/if_pflow.h sys/contrib/pf/net/if_pflow.h
--- sys.old/contrib/pf/net/if_pflow.h	2011-06-28 13:57:25.0 +0200
+++ sys/contrib/pf/net/if_pflow.h	2011-11-13 14:12:41.130906469 +0100
@@ -66,7 +66,7 @@
 	unsigned int		 sc_maxcount;
 	u_int64_t		 sc_gcounter;
 	struct ip_moptions	 sc_imo;
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 	struct callout		 sc_tmo;
 #else
 	struct timeout		 sc_tmo;
diff -ur sys.old/contrib/pf/net/if_pfsync.h sys/contrib/pf/net/if_pfsync.h
--- sys.old/contrib/pf/net/if_pfsync.h	2011-06-28 13:57:25.0 +0200
+++ sys/contrib/pf/net/if_pfsync.h	2011-11-13 14:12:41.131906257 +0100
@@ -268,7 +268,7 @@
 	int		 pfsyncr_authlevel;
 };
 
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #define	SIOCSETPFSYNC   _IOW('i', 247, struct ifreq)
 #define	SIOCGETPFSYNC   _IOWR('i', 248, 

Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-22 Thread Robert Millan
On Tue, Nov 22, 2011 at 11:35:15AM +0200, Kostik Belousov wrote:
 I am fine with __FreeBSD_kernel being empty, please submit the patch.

Here.

-- 
Robert Millan
Index: sys/sys/param.h
===
--- sys/sys/param.h	(revision 227580)
+++ sys/sys/param.h	(working copy)
@@ -60,6 +60,22 @@
 #undef __FreeBSD_version
 #define __FreeBSD_version 101	/* Master, propagated to newvers */
 
+/*
+ * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD,
+ * which by definition is always true on FreeBSD. This macro is also defined
+ * on other systems that use the kernel of FreeBSD, such as GNU/kFreeBSD
+ *
+ * It is tempting to use this macro in userland code when we want to enable
+ * kernel-specific routines, and in fact it's fine to do this in code that
+ * is part of FreeBSD itself.  However, be aware that as presence of this
+ * macro is still not widespread (e.g. older FreeBSD versions, 3rd party
+ * compilers, etc), it is STRONGLY DISCOURAGED to check for this macro in
+ * external applications without also checking for __FreeBSD__ as an
+ * alternative.
+ */
+#undef __FreeBSD_kernel__
+#define __FreeBSD_kernel__
+
 #ifdef _KERNEL
 #define	P_OSREL_SIGWAIT		70
 #define	P_OSREL_SIGSEGV		74


signature.asc
Description: Digital signature


Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-22 Thread Robert Millan
2011/11/22 John Baldwin j...@freebsd.org:
 Is __FreeBSD_version defined if __FreeBSD_kernel__ is defined on kFreeBSD?

Not currently (except for kernel-space code), but if all the checks
that use __FreeBSD_version are like the one you describe, I think it'd
make sense.

But we need to make sure that defining it wouldn't suddenly enable
code that is intended for FreeBSD userland, like it happens with
__FreeBSD__.

It'd also have to be discussed on Debian mailing list.  My first
impression is that defining it could be useful in some situations.  We
just don't run into this kind of situation so often, so this
possibility AFAIK has never been discussed.  I had it in my TODO to
bring it up.

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-22 Thread Robert Millan
Hi Ed,

2011/11/22 Ed Schouten e...@80386.nl:
 +#undef __FreeBSD_kernel__
 +#define __FreeBSD_kernel__

 So why not remove the #undef and not let the compiler define it at all?

Well I have no objection if the #undef is removed.

I don't understand why you consider it a problem though.  It's not
terribly useful but if compilers can opt in and define it (usually as
an empty macro), this doesn't hurt either AFAICT.  The problem I
described before was about compilers being forced to provide a number.

Anyhow, I don't think it makes a big difference.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-22 Thread Robert Millan
2011/11/22 John Baldwin j...@freebsd.org:
 Not currently (except for kernel-space code), but if all the checks
 that use __FreeBSD_version are like the one you describe, I think it'd
 make sense.

 I can think of cases where you might want it exposed (e.g. in the parts
 of net-snmp that grovel around in kernel data structures and use
 __FreeBSD_version to figure out what the right thing to do is, possibly
 the same with lsof).

 But we need to make sure that defining it wouldn't suddenly enable
 code that is intended for FreeBSD userland, like it happens with
 __FreeBSD__.

 Correct.  I don't believe that is the case since normally one has to
 check for __FreeBSD__ before using __FreeBSD_version.

Makes sense.  I'll bring this up in debian-bsd mailing list.

Thanks for the tip

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


[PATCH] Detect GNU/kFreeBSD in user-visible kernel headers (v2)

2011-11-22 Thread Robert Millan

Here we go again :-)

Out of the kernel headers that are installed in /usr/include/ hierracy, there
are some which include support multiple operating systems (usually FreeBSD and
other *BSD flavours).

This patch adds support to detect GNU/kFreeBSD as well.  In all cases, we
match the same declarations as FreeBSD does (which is to be expected in kernel
headers, since both systems share the same kernel).

-- 
Robert Millan
Index: sys/cam/scsi/scsi_low.h
===
--- sys/cam/scsi/scsi_low.h	(revision 227831)
+++ sys/cam/scsi/scsi_low.h	(working copy)
@@ -44,6 +44,8 @@
 #ifndef	_SCSI_LOW_H_
 #define	_SCSI_LOW_H_
 
+#include sys/param.h
+
 /*
  * Scsi low OSDEP 
  * (All os depend structures should be here!)
@@ -53,10 +55,10 @@
 #define	SCSI_LOW_INTERFACE_XS
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#ifdef	__FreeBSD_kernel__
 #define	SCSI_LOW_INTERFACE_CAM
 #define	CAM
-#endif	/* __FreeBSD__ */
+#endif	/* __FreeBSD_kernel__ */
 
 / includes ***/
 #ifdef	__NetBSD__
@@ -64,7 +66,7 @@
 #include dev/isa/ccbque.h
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#ifdef	__FreeBSD_kernel__
 #include sys/device_port.h
 #include sys/kdb.h
 #include cam/cam.h
@@ -75,7 +77,7 @@
 
 #include cam/scsi/scsi_dvcfg.h
 #include i386/isa/ccbque.h
-#endif	/* __FreeBSD__ */
+#endif	/* __FreeBSD_kernel__ */
 
 / functions macro /
 #ifdef	__NetBSD__
@@ -85,13 +87,13 @@
 #define	SCSI_LOW_BZERO(pt, size)	memset((pt), 0, (size))
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#ifdef	__FreeBSD_kernel__
 #undef	MSG_IDENTIFY
 #define	SCSI_LOW_DEBUGGER(dev)	kdb_enter(KDB_WHY_CAM, dev)
 #define	SCSI_LOW_DELAY(mu)	DELAY((mu))
 #define	SCSI_LOW_SPLSCSI	splcam
 #define	SCSI_LOW_BZERO(pt, size)	bzero((pt), (size))
-#endif	/* __FreeBSD__ */
+#endif	/* __FreeBSD_kernel__ */
 
 / os depend interface structures **/
 #ifdef	__NetBSD__
@@ -111,7 +113,7 @@
 };
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#ifdef	__FreeBSD_kernel__
 typedef	struct scsi_sense_data scsi_low_osdep_sense_data_t;
 
 struct scsi_low_osdep_interface {
@@ -134,7 +136,7 @@
 
 struct scsi_low_osdep_lun_interface {
 };
-#endif	/* __FreeBSD__ */
+#endif	/* __FreeBSD_kernel__ */
 
 / os depend interface functions */
 struct slccb;
Index: sys/cam/scsi/scsi_low_pisa.h
===
--- sys/cam/scsi/scsi_low_pisa.h	(revision 227831)
+++ sys/cam/scsi/scsi_low_pisa.h	(working copy)
@@ -34,14 +34,16 @@
 #ifndef	_SCSI_LOW_PISA_H_
 #define	_SCSI_LOW_PISA_H_
 
+#include sys/param.h
+
 #ifdef	__NetBSD__
 int scsi_low_activate_pisa(pisa_device_handle_t);
 int scsi_low_deactivate_pisa(pisa_device_handle_t);
 int scsi_low_notify_pisa(pisa_device_handle_t, pisa_event_t);
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#ifdef	__FreeBSD_kernel__
 int scsi_low_activate_pisa(struct scsi_low_softc *, int);
 int scsi_low_deactivate_pisa(struct scsi_low_softc *);
-#endif	/* __FreeBSD__ */
+#endif	/* __FreeBSD_kernel__ */
 #endif	/* !_SCSI_LOW_PISA_H_ */
Index: sys/contrib/altq/altq/altq_var.h
===
--- sys/contrib/altq/altq/altq_var.h	(revision 227831)
+++ sys/contrib/altq/altq/altq_var.h	(working copy)
@@ -201,7 +201,7 @@
 #define	CALLOUT_STOP(c)		untimeout((c)-c_func,(c)-c_arg)
 #define	CALLOUT_INITIALIZER	{ NULL, NULL }
 #endif
-#if !defined(__FreeBSD__)
+#if !defined(__FreeBSD_kernel__)
 typedef void (timeout_t)(void *);
 #endif
 
Index: sys/contrib/altq/altq/if_altq.h
===
--- sys/contrib/altq/altq/if_altq.h	(revision 227831)
+++ sys/contrib/altq/altq/if_altq.h	(working copy)
@@ -29,7 +29,9 @@
 #ifndef _ALTQ_IF_ALTQ_H_
 #define	_ALTQ_IF_ALTQ_H_
 
-#ifdef __FreeBSD__
+#include sys/param.h
+
+#ifdef __FreeBSD_kernel__
 #include sys/lock.h		/* XXX */
 #include sys/mutex.h		/* XXX */
 #include sys/event.h		/* XXX */
@@ -51,7 +53,7 @@
 	int	ifq_len;
 	int	ifq_maxlen;
 	int	ifq_drops;
-#ifdef __FreeBSD__
+#ifdef __FreeBSD_kernel__
 	struct	mtx ifq_mtx;
 #endif
 
Index: sys/contrib/pf/net/if_pflog.h
===
--- sys/contrib/pf/net/if_pflog.h	(revision 227831)
+++ sys/contrib/pf/net/if_pflog.h	(working copy)
@@ -27,10 +27,12 @@
 #ifndef _NET_IF_PFLOG_H_
 #define	_NET_IF_PFLOG_H_
 
+#include sys/param.h
+
 #define	PFLOGIFS_MAX	16
 
 struct pflog_softc {
-#ifdef __FreeBSD__
+#ifdef __FreeBSD_kernel__
 	struct ifnet		*sc_ifp;	/* the interface pointer */
 #else
 	struct ifnet		sc_if;		/* the interface */
@@ -74,7 +76,7 @@
 #define	OLD_PFLOG_HDRLEN	sizeof(struct old_pfloghdr)
 
 #ifdef _KERNEL
-#ifdef __FreeBSD__
+#ifdef __FreeBSD_kernel__
 struct pf_rule;
 struct pf_ruleset;
 struct pfi_kif;
@@ -90,7 +92,7 @@
 	if (pflog_packet_ptr != NULL

Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-21 Thread Robert Millan
(replying with Debian hat this time)

2011/11/21 Kostik Belousov kostik...@gmail.com:
 There are some implementations that
 use FreeBSD kernel, and which could potentially benefit from providing
 its own value for __FreeBSD_kernel.

Actually, we wouldn't be able to provide a different value for the
macro (whatever its name). Our compiler simply doesn't know which
version of the kernel it is building for. Only the headers do, but if
we define it in the headers we'd just use the FreeBSD definitions.

Our compiler defines __FreeBSD_kernel__ as an empty macro, I don't
expect this will change because unlike with FreeBSD, on Debian there
are strong technical limitations to making it a number.

If __FreeBSD_kernel__ is to be defined in FreeBSD land, may I suggest
that it is defined as an empty macro as well? This covers the vast
majority of cases (e.g. like the ones in my initial patch which
started this discussion), and it doesn't preclude the possibility that
this macro becomes a number without breaking backward compatibility.

OTOH once you define it as a number, it becomes relevant whether you
did it with #ifndef or with #undef, and so you have to commit to it.

Just to make it clear: It's no problem to me if it's defined as a
number, but it doesn't help much either. At least from Debian POV it's
not worth making a big argument about. It could be a good idea from
FreeBSD POV, but please only do this if it's useful to FreeBSD.

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-20 Thread Robert Millan
On Sat, Nov 19, 2011 at 07:56:20PM +0200, Kostik Belousov wrote:
 I fully agree with an idea that compiler is not an authorative source
 of the knowledge of the FreeBSD version. Even more, I argue that we shall
 not rely on compiler for this at all. Ideally, we should be able to
 build FreeBSD using the stock compilers without local modifications.
 Thus relying on the symbols defined by compiler, and not the source
 is the thing to avoid and consistently remove.
 
 We must do this to be able to use third-party tooldchain for FreeBSD builds.
 
 That said, why not define __FreeBSD_kernel as equal to __FreeBSD_version ?
 And then make more strong wording about other systems that use the macro,
 e.g. remove 'may' from the kFreeBSD example.
 Also, please remove the smile from comment.

Ok. New patch attached.

-- 
Robert Millan
Index: sys/sys/param.h
===
--- sys/sys/param.h	(revision 227580)
+++ sys/sys/param.h	(working copy)
@@ -60,6 +60,22 @@
 #undef __FreeBSD_version
 #define __FreeBSD_version 101	/* Master, propagated to newvers */
 
+/*
+ * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD,
+ * which by definition is always true on FreeBSD. This macro is also defined
+ * on other systems that use the kernel of FreeBSD, such as GNU/kFreeBSD
+ *
+ * It is tempting to use this macro in userland code when we want to enable
+ * kernel-specific routines, and in fact it's fine to do this in code that
+ * is part of FreeBSD itself.  However, be aware that as presence of this
+ * macro is still not widespread (e.g. older FreeBSD versions, 3rd party
+ * compilers, etc), it is STRONGLY DISCOURAGED to check for this macro in
+ * external applications without also checking for __FreeBSD__ as an
+ * alternative.
+ */
+#undef __FreeBSD_kernel__
+#define __FreeBSD_kernel__ __FreeBSD_version
+
 #ifdef _KERNEL
 #define	P_OSREL_SIGWAIT		70
 #define	P_OSREL_SIGSEGV		74


signature.asc
Description: Digital signature


Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-19 Thread Robert Millan
2011/11/18 Robert Millan r...@freebsd.org:
 2011/11/17 John Baldwin j...@freebsd.org:
 Hmm, I wonder if it's better to use the #ifndef approach rather than #undef
 so that when compilers are updated to DTRT we will honor their settings?

 Well, the compiler is supposed to know better than sys/param.h,

I gave this a bit more thought

The compiler knows about the system it was intended to build for, but
sys/param.h *is* part of the system we're building for.  It's
impossible for sys/param.h to have the wrong information unless it's
out of sync with the rest of the headers.

As for the compiler, on FreeBSD it's hard for the compiler to be out
of sync, because the system (in comparison with others) is tightly
packaed and upgrade procedures are well defined.

But if you take Debian, for example, we use the same compiler to build
8-STABLE, 9-STABLE and 10-CURRENT kernels.  The compiler has no idea
which version of FreeBSD the sources it is building come from.

I wouldn't put compilers in general in a position where they're forced
to know the FreeBSD major version beforehand because sys/param.h will
give preference to the information coming from compiler.

I propose this alternate patch which derives the major number from
__FreeBSD_version instead.
Index: sys/sys/param.h
===
--- sys/sys/param.h	(revision 227580)
+++ sys/sys/param.h	(working copy)
@@ -60,6 +60,23 @@
 #undef __FreeBSD_version
 #define __FreeBSD_version 101	/* Master, propagated to newvers */
 
+/*
+ * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD,
+ * which by definition is always true on FreeBSD :-). This macro may also
+ * be defined on other systems that use the kernel of FreeBSD, such as
+ * GNU/kFreeBSD.
+ *
+ * It is tempting to use this macro in userland code when we want to enable
+ * kernel-specific routines, and in fact it's fine to do this in code that
+ * is part of FreeBSD itself.  However, be aware that as presence of this
+ * macro is still not widespread (e.g. older FreeBSD versions, 3rd party
+ * compilers, etc), it is STRONGLY DISCOURAGED to check for this macro in
+ * external applications without also checking for __FreeBSD__ as an
+ * alternative.
+ */
+#undef __FreeBSD_kernel__
+#define __FreeBSD_kernel__ (__FreeBSD_version / 10)
+
 #ifdef _KERNEL
 #define	P_OSREL_SIGWAIT		70
 #define	P_OSREL_SIGSEGV		74
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-17 Thread Robert Millan
2011/11/17 John Baldwin j...@freebsd.org:
 I recall the discussion from earlier.  I can't recall if I had replied to it
 though. :-/  In my current opinion, I think it would be fine to define
 __FreeBSD_kernel__ on FreeBSD and to do it in sys/param.h for now until all
 the compilers we use have been updated to define it automatically (which may
 be a long time).  I think it will also be fine to patch in-system headers to
 use __FreeBSD_kernel__ once sys/param.h is defined.  Unfortunately headers
 in 3rd party software are going to have to check for both __FreeBSD__ and
 __FreeBSD_kernel__ to support both GNU/kFreeBSD and older FreeBSD for the
 foreseeable future.  I think that is fine, but that the sooner we add
 __FreeBSD_kernel__ on FreeBSD the sooner we get the clock started for a day
 when those extra checks can go away.  I would also be fine with MFC'ing the
 addition of __FreeBSD_kernel__ to older branches (at least 7 - 9) as well.

Well, here's a patch then.  I wrote a comment in it trying to explain
the situation.  Please let me know what you think.
Index: sys/sys/param.h
===
--- sys/sys/param.h	(revision 227580)
+++ sys/sys/param.h	(working copy)
@@ -60,6 +60,23 @@
 #undef __FreeBSD_version
 #define __FreeBSD_version 101	/* Master, propagated to newvers */
 
+/*
+ * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD,
+ * which by definition is always true on FreeBSD :-). This macro may also
+ * be defined on other systems that use the kernel of FreeBSD, such as
+ * GNU/kFreeBSD.
+ *
+ * It is tempting to use this macro in userland code when we want to enable
+ * kernel-specific routines, and in fact it's fine to do this in code that
+ * is part of FreeBSD itself.  However, be aware that as presence of this
+ * macro is still not widespread (e.g. older FreeBSD versions, 3rd party
+ * compilers, etc), it is STRONGLY DISCOURAGED to check for this macro in
+ * external applications without also checking for __FreeBSD__ as an
+ * alternative.
+ */
+#undef __FreeBSD_kernel__
+#define __FreeBSD_kernel__ __FreeBSD__
+
 #ifdef _KERNEL
 #define	P_OSREL_SIGWAIT		70
 #define	P_OSREL_SIGSEGV		74
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-17 Thread Robert Millan
2011/11/17 John Baldwin j...@freebsd.org:
 Hmm, I wonder if it's better to use the #ifndef approach rather than #undef
 so that when compilers are updated to DTRT we will honor their settings?

Well, the compiler is supposed to know better than sys/param.h,
because it inherited this number from the runtime kernel when it was
built.

However, __FreeBSD__ comes from the compiler already so if you
#define __FreeBSD_kernel__ __FreeBSD__ you get the information from
the compiler anyway.

As both approaches do the same thing, I really don't mind either way.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


[PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-16 Thread Robert Millan
Hi!

Out of the kernel headers that are installed in /usr/include/ hierracy, there
are some which include support multiple operating systems (usually FreeBSD and
other *BSD flavours).

This patch adds support to detect GNU/kFreeBSD as well.  In all cases, we
match the same declarations as FreeBSD does (which is to be expected in kernel
headers, since both systems share the same kernel).

Does it look fine?
diff -ur sys.old/cam/scsi/scsi_low.h sys/cam/scsi/scsi_low.h
--- sys.old/cam/scsi/scsi_low.h	2007-12-25 18:52:02.0 +0100
+++ sys/cam/scsi/scsi_low.h	2011-11-13 14:12:41.121908380 +0100
@@ -53,7 +53,7 @@
 #define	SCSI_LOW_INTERFACE_XS
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #define	SCSI_LOW_INTERFACE_CAM
 #define	CAM
 #endif	/* __FreeBSD__ */
@@ -64,7 +64,7 @@
 #include dev/isa/ccbque.h
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #include sys/device_port.h
 #include sys/kdb.h
 #include cam/cam.h
@@ -85,7 +85,7 @@
 #define	SCSI_LOW_BZERO(pt, size)	memset((pt), 0, (size))
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #undef	MSG_IDENTIFY
 #define	SCSI_LOW_DEBUGGER(dev)	kdb_enter(KDB_WHY_CAM, dev)
 #define	SCSI_LOW_DELAY(mu)	DELAY((mu))
@@ -111,7 +111,7 @@
 };
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 typedef	struct scsi_sense_data scsi_low_osdep_sense_data_t;
 
 struct scsi_low_osdep_interface {
diff -ur sys.old/cam/scsi/scsi_low_pisa.h sys/cam/scsi/scsi_low_pisa.h
--- sys.old/cam/scsi/scsi_low_pisa.h	2005-01-05 23:34:37.0 +0100
+++ sys/cam/scsi/scsi_low_pisa.h	2011-11-13 14:12:41.121908380 +0100
@@ -40,7 +40,7 @@
 int scsi_low_notify_pisa(pisa_device_handle_t, pisa_event_t);
 #endif	/* __NetBSD__ */
 
-#ifdef	__FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 int scsi_low_activate_pisa(struct scsi_low_softc *, int);
 int scsi_low_deactivate_pisa(struct scsi_low_softc *);
 #endif	/* __FreeBSD__ */
diff -ur sys.old/contrib/altq/altq/altq_var.h sys/contrib/altq/altq/altq_var.h
--- sys.old/contrib/altq/altq/altq_var.h	2011-03-10 19:49:15.0 +0100
+++ sys/contrib/altq/altq/altq_var.h	2011-11-13 14:12:41.118907341 +0100
@@ -201,7 +201,7 @@
 #define	CALLOUT_STOP(c)		untimeout((c)-c_func,(c)-c_arg)
 #define	CALLOUT_INITIALIZER	{ NULL, NULL }
 #endif
-#if !defined(__FreeBSD__)
+#if !defined(__FreeBSD__)  !defined(__FreeBSD_kernel__)
 typedef void (timeout_t)(void *);
 #endif
 
diff -ur sys.old/contrib/altq/altq/if_altq.h sys/contrib/altq/altq/if_altq.h
--- sys.old/contrib/altq/altq/if_altq.h	2011-03-10 19:49:15.0 +0100
+++ sys/contrib/altq/altq/if_altq.h	2011-11-13 14:12:41.119907128 +0100
@@ -29,7 +29,7 @@
 #ifndef _ALTQ_IF_ALTQ_H_
 #define	_ALTQ_IF_ALTQ_H_
 
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #include sys/lock.h		/* XXX */
 #include sys/mutex.h		/* XXX */
 #include sys/event.h		/* XXX */
@@ -51,7 +51,7 @@
 	int	ifq_len;
 	int	ifq_maxlen;
 	int	ifq_drops;
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 	struct	mtx ifq_mtx;
 #endif
 
diff -ur sys.old/contrib/pf/net/if_pflog.h sys/contrib/pf/net/if_pflog.h
--- sys.old/contrib/pf/net/if_pflog.h	2011-06-28 13:57:25.0 +0200
+++ sys/contrib/pf/net/if_pflog.h	2011-11-13 14:12:41.130906469 +0100
@@ -30,7 +30,7 @@
 #define	PFLOGIFS_MAX	16
 
 struct pflog_softc {
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 	struct ifnet		*sc_ifp;	/* the interface pointer */
 #else
 	struct ifnet		sc_if;		/* the interface */
@@ -74,7 +74,7 @@
 #define	OLD_PFLOG_HDRLEN	sizeof(struct old_pfloghdr)
 
 #ifdef _KERNEL
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 struct pf_rule;
 struct pf_ruleset;
 struct pfi_kif;
diff -ur sys.old/contrib/pf/net/if_pflow.h sys/contrib/pf/net/if_pflow.h
--- sys.old/contrib/pf/net/if_pflow.h	2011-06-28 13:57:25.0 +0200
+++ sys/contrib/pf/net/if_pflow.h	2011-11-13 14:12:41.130906469 +0100
@@ -66,7 +66,7 @@
 	unsigned int		 sc_maxcount;
 	u_int64_t		 sc_gcounter;
 	struct ip_moptions	 sc_imo;
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 	struct callout		 sc_tmo;
 #else
 	struct timeout		 sc_tmo;
diff -ur sys.old/contrib/pf/net/if_pfsync.h sys/contrib/pf/net/if_pfsync.h
--- sys.old/contrib/pf/net/if_pfsync.h	2011-06-28 13:57:25.0 +0200
+++ sys/contrib/pf/net/if_pfsync.h	2011-11-13 14:12:41.131906257 +0100
@@ -268,7 +268,7 @@
 	int		 pfsyncr_authlevel;
 };
 
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
 #define	SIOCSETPFSYNC   _IOW('i', 247, struct ifreq)
 #define	SIOCGETPFSYNC   _IOWR('i', 248, struct ifreq)
 #endif
@@ -288,7 +288,7 @@
 #define	PFSYNC_S_DEFER	0xfe
 #define	PFSYNC_S_NONE	0xff
 
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || 

Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-16 Thread Robert Millan
2011/11/16 Xin LI delp...@delphij.net:
 Just my $0.02 -- I think we should probably do it in a more
 centralized place -- otherwise in case someone imported some new code,
 they have to do the same defined(__FreeBSD__) ||
 defined(__FreeBSD_kernel__)?

How about something like:

#if defined(__FreeBSD__)  !defined(__FreeBSD_kernel__)
#define __FreeBSD_kernel__
#endif

it can be placed at beginning of each header, then the rest becomes
much simpler.

Note this has the side-effect of defining __FreeBSD_kernel__ on
FreeBSD, which I suspect some people won't be fond of.  An alternative
could be to come up with an ad-hoc macro that means this system is
either FreeBSD or uses the same kernel as FreeBSD and define it where
needed.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers

2011-11-16 Thread Robert Millan
2011/11/16 Warner Losh i...@bsdimp.com:
 My second reaction was why not have

 #ifndef __FreeBSD_kernel__
 #define __FreeBSD_kernel__ __FreeBSD__
 #endif

 in sys/param.h and then just change __FreeBSD__ to __FreeBSD_kernel__ in the 
 headers that are affected?  But I'm not quite sure what effects that would 
 have on your environment.

I'm fine with this.

 Why do you think people wouldn't be fond of the __FreeBSD_kernel__ being 
 defined?

See archived discussion:

http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035721.html

particularly this mail in which you participated:

http://lists.freebsd.org/pipermail/freebsd-hackers/2011-July/035823.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [PATCH] Fix NKPT kernel config option

2011-09-02 Thread Robert Millan
2011/9/1 John Baldwin j...@freebsd.org:
 In general we force the relevant C files to use opt_*.h includes and avoid
 nested includes of those in headers.

With this approach I can't trust that this feature will do the right
thing.  I would rather modify pmap.h by hand than run the unnecessary
risk.

 Do you know of any C files that do
 are using NKPT (or values derived from it) without including opt_pmap.h?

Many.  To obtain a full list, I suggest you put something like:

#ifdef NKPT
#warning nkpt:good
#else
#warning nkpt:bad
#endif

in pmap.h and build with WERROR=

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [PATCH] Fix NKPT kernel config option

2011-09-02 Thread Robert Millan
2011/9/2 John Baldwin j...@freebsd.org:
 A more useful test would be to alter pmap.h so it says:

 #ifndef NKPT
 #define NKPT doesnt_compile
 #endif

Uhm fair enough, thanks for the explanation John.

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


[PATCH] Fix NKPT kernel config option

2011-09-01 Thread Robert Millan
Hi John,

Thanks for adding an NKPT kernel config option (r225194), but this
doesn't seem to work unless opt_pmap.h is included, see attached
patch.

Without this include, there's no garantee that the NKPT definition code:

#ifndef NKPT
#define NKPT32
#endif

will use the value specified in config.  Or worse, it may even use
different values for different .c files.

-- 
Robert Millan
Index: kfreebsd-9/sys/amd64/include/pmap.h
===
--- kfreebsd-9.orig/sys/amd64/include/pmap.h	2011-08-31 22:26:06.0 +0200
+++ kfreebsd-9/sys/amd64/include/pmap.h	2011-09-01 21:31:41.650902274 +0200
@@ -45,6 +45,8 @@
 #ifndef _MACHINE_PMAP_H_
 #define	_MACHINE_PMAP_H_
 
+#include opt_pmap.h
+
 /*
  * Page-directory and page-table entries follow this format, with a few
  * of the fields not present here and there, depending on a lot of things.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules]

2011-07-15 Thread Robert Millan
2011/6/26 Warner Losh i...@bsdimp.com:
 I like the idea of having a standardized table.  I've done this with PC Card 
 and it really works well.  It isn't the design pattern that all drivers use, 
 and it may be hard to get everyone lined up on this.  I tried PCI back after 
 I did PC Card and met resistance.  Most of the resistance was from people 
 that are no longer active in the project, so I think that we could do this 
 today.   I suspect that some of the vendor drivers today might stand in the 
 way of having PCI be completely uniform.

 The big advantage of USB is that it is uniform now.  PCI isn't.  It would 
 take a lot of work to make it uniform.

If only some PCI drivers can be made uniform, why not provide devd
autoload support only to those drivers whose maintainers choose to
make them uniform?  This would give those opposing uniformity a
compelling reason to change their view, without forcing them into it.

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-12 Thread Robert Millan
2011/7/12 Kostik Belousov kostik...@gmail.com:
 I just committed this to HEAD. Will MFC in a week, unless some problems
 arise.

Thanks!

 I will bump revision for stable/8 when merging, but I do not see much
 reason to bump on HEAD right now.

Uhm I think we can survive without a bump in HEAD.  For now we will
need to keep our backward-compatibility patch anyway, and when the
bump happens on stable/8 our sysctl comparison will identify 900039 as
new ABI.

Petr is that correct?

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [PATCH] Improve LinuxThreads compatibility in rfork()

2011-07-11 Thread Robert Millan
2011/7/11 Kostik Belousov kostik...@gmail.com:
 I shall state that the sig == SIGCHLD case is ugly. Having the separate
 flag do not send signal to the parent would be much less clumsy.
 What are the requirements for the ABI stability for Debian/kFreeBSD ?
 Can this be fixed now, or is it too late ?

Perhaps we could make a smooth transition by implementing both methods
on our kernel, then update glibc to use the new one, and only remove
the deprecated method in our kernel after a full release cycle.

Petr, do you think this could fly? We'd be breaking backward
compatibility in userland, but if I understand correctly we do this
already and our only supported upgrade path is first upgrade kernel,
then userland anyway.

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [RFT] Automatic load of USB kernel modules

2011-06-29 Thread Robert Millan
2011/6/24 Hans Petter Selasky hsela...@c2i.net:
 I would like to request testing of the attached
 patch before I commit it. The patch is about only having ukbd, ums and umass
 per default in the kernel GENERIC config file(s).

What about urio?

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: [RFT] Automatic load of USB kernel modules

2011-06-29 Thread Robert Millan
2011/6/29 Hans Petter Selasky hsela...@c2i.net:
 What about urio?

 Hi,

 urio is not used for booting the kernel, so it is not important that it is in
 the kernel.

Ah, ok.  I thought /dev/urio0 was a block device.

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: Automatic load of PCI kernel modules [WAS: [RFT] Automatic load of USB kernel modules]

2011-06-26 Thread Robert Millan
2011/6/26 Hans Petter Selasky hsela...@c2i.net:
 Hi,

 I see that a lot of PCI device drivers use code to check their ID's.

 [...]

I seem to recall devd doesn't process PCI because it is event-driven and
there are no events associated with PCI cards.

Perhaps it could be modified to scan for PCI cards via libpci on initialization
and generate fake events for them?

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: misc/157903: automated kldload for USB class devices

2011-06-24 Thread Robert Millan
2011/6/24 Hans Petter Selasky hsela...@c2i.net:
 Updated bus_auto.conf:

 http://hselasky.homeunix.org:8192/bus_auto.conf

Very nice.  But why not use variable names instead of hardcoding numbers?  It
makes the output much easier to understand.

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org


Re: misc/157903: automated kldload for USB class devices

2011-06-24 Thread Robert Millan
2011/6/24 Hans Petter Selasky hsela...@c2i.net:
 Very nice.  But why not use variable names instead of hardcoding numbers?
 It makes the output much easier to understand.

 To save memory.

I haven't inspected devd code, but I was under the assumption that
variables only lived untill resolved.  What would be the point of keeping
them in memory after devd has finished parsing the config files?

-- 
Robert Millan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org