On Thu, 13 Dec 2012, Pawel Jakub Dawidek wrote:
On Thu, Dec 13, 2012 at 08:16:21PM +0200, Konstantin Belousov wrote:
On Thu, Dec 13, 2012 at 05:55:41PM +0100, Pawel Jakub Dawidek wrote:
On Thu, Dec 13, 2012 at 06:12:42PM +0200, Konstantin Belousov wrote:
On Thu, Dec 13, 2012 at 12:12:44PM +0100, Pawel Jakub Dawidek wrote:
On Wed, Dec 12, 2012 at 11:06:52PM +0200, Konstantin Belousov wrote:
I saw CTLFLAG_TUN on the sysctl and assumed it is read-only...
How about defining BSD_PID_MAX in sys/proc.h, which would be visible by
userland as well and setting PID_MAX to BSD_PID_MAX?
This would also help bsnmpd.
http://people.freebsd.org/~pjd/patches/PID_MAX.patch
Do you know why PID_MAX is under _KERNEL ? If there is no real reason,
it would be better to move it outside kernel-only section. sys/proc.h
is not in POSIX anyway.
I don't really know, but POSIX says that {PID_MAX} is intentionally left
out of POSIX because pids_t might be cookies in a very large address
space so that there is no useful use of {PID_MAX}. (POSIX doesn't
say exactly this. It says "arrays of values of this type [uid_t, gid_t
or pid_t] are unlikely to be fully portable".)
I assumed it will break some ports that may define it themselves.
I wonder if we could do a test ports build to see what's the impact.
Sure.
On the other hand, sys/proc.h is mostly useless for the application code
as it is now. Might be, use
#ifndef PID_MAX
braces ?
Ugh. If there is any useful use of {PID_MAX}, then this just breaks
detection of using the wrong value.
This can be done of course, but it won't help cases where PID_MAX is
defined after sys/proc.h is included.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
