sys/proc.h inclusion of sys/time.h

Warner Losh imp at bsdimp.com
Tue Jul 8 20:52:28 UTC 2014


On Jul 8, 2014, at 2:06 PM, Bryan Drewery <bdrewery at freebsd.org> wrote:

> In r34924 sys/proc.h was changed to only include sys/time.h if not building in kernel.
> 
> However, as the comment next to time.h says itimerval is needed.
> 
> struct proc {
> ..
> struct itimerval p_realtimer;   /* (c) Alarm timer. */
> 
> This manifests when (hackishly) including sys/proc.h with _KERNEL defined:
> 
>> In file included from /root/svn/base/usr.sbin/tcpdump/tcpdump/../../../contrib/tcpdump/print-pflog.c:37:
>> /usr/include/sys/proc.h:524:19: error: field has incomplete type 'struct itimerval'
>>        struct itimerval p_realtimer;   /* (c) Alarm timer. */
> 
> (Why am I doing this? I need PID_MAX and NO_PID for a tcpdump change I am testing that is intended for upstreaming. Perhaps I can use kern.pid_max in __FreeBSD__ and other hacks on other platforms, I have not yet decided on this.)
> 
> Should we move the inclusion of sys/time.h outside of this ifdef or just add a forward declaration for struct itimerval above struct proc like many others?

In the kernel, usually we just include sys/time.h before including sys/proc.h. :) Traditionally, we haven’t included all the pre-reqs and left it to users of these files to do so. Should we change it? Not without a good reason, imho, but honestly I think any reason better than “I think it would be cool” is likely good enough these days since n^2 I/O behavior of always including all prereq files isn’t as big a deal as it once was...

We can’t do the forward struct declaration because by the time we get around to defining (not using) struct proc, its size must be known.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20140708/86b06989/attachment.sig>


More information about the freebsd-arch mailing list