Re: namespace pollution with struct thread?

2001-11-13 Thread Dag-Erling Smorgrav

John Baldwin [EMAIL PROTECTED] writes:
 On 12-Nov-01 Julian Elischer wrote:
  On the other hand we might conceivably be able to 
  stop the export from the kernel of this struct type.
 Not unless we stop exporting struct proc since each proc has an
 embedded thread.

We don't really need to export struct proc now that we have struct
kinfo_proc, do we?  The few userland libraries and programs that still
need it (basically libkvm and gdb - libkvm consumers such as top only
need to have it declared, not defined) could define something like
_NEED_STRUCT_PROC before including sys/proc.h.

One other thing worth pointing out is that there is no reason for
sys/user.h to include sys/proc.h.  It just needs to declare struct
proc as an opaque structure.  Also, sys/user.h currently pulls in a
lot of other headers such as sys/_lock.h and sys/_mutex.h that are
needed only because sys/proc.h depends on them.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: namespace pollution with struct thread?

2001-11-13 Thread Julian Elischer



On 14 Nov 2001, Dag-Erling Smorgrav wrote:
 
 One other thing worth pointing out is that there is no reason for
 sys/user.h to include sys/proc.h.  It just needs to declare struct
 proc as an opaque structure.  Also, sys/user.h currently pulls in a
 lot of other headers such as sys/_lock.h and sys/_mutex.h that are
 needed only because sys/proc.h depends on them.


In this case it doesn't even need to include user.h

it still compiles and runs without including it

 
 DES
 -- 
 Dag-Erling Smorgrav - [EMAIL PROTECTED]
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: namespace pollution with struct thread?

2001-11-13 Thread Bruce Evans

On 14 Nov 2001, Dag-Erling Smorgrav wrote:

 One other thing worth pointing out is that there is no reason for
 sys/user.h to include sys/proc.h.  It just needs to declare struct
 proc as an opaque structure.

I tried removing it a moth or two ago, but gave up.  There was too much
secondary namespace pollution that should be cleaned up first.

 Also, sys/user.h currently pulls in a
 lot of other headers such as sys/_lock.h and sys/_mutex.h that are
 needed only because sys/proc.h depends on them.

These are needed for sys/ucred.h too (except sys/ucred.h includes
them itself).  The struct mtx in sys/ucred.h is one of the main sources
of secondary pollution.  struct ucred insn't inside the _KERNEL ifdef
because a few parts of userland still need it.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



namespace pollution with struct thread?

2001-11-12 Thread Steve Kargl

Recent versions of WINE have defined a struct thread in
wine/server/thread.h.  Unfortunately, wine/server/context_i386.c
sucks in sys/user.h, which brings in sys/proc.h.  Of
course, sys/proc.h contains the post-KSE integrated 
struct thread.  I've managed to build WINE by temporarily
placing a #ifdef _KERNEL ... #endif in sys/proc.h.

I WINE developer has suggested that this is namespace
pollution on the part of FreeBSD, but he hasn't given
any details to support what he means.

So, should parts of sys/proc.h be protected by _KERNEL.

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



namespace pollution with struct thread?

2001-11-12 Thread Garrett Wollman

On Mon, 12 Nov 2001 14:01:35 -0800, Steve Kargl [EMAIL PROTECTED] 
said:

 I WINE developer has suggested that this is namespace
 pollution on the part of FreeBSD, but he hasn't given
 any details to support what he means.

Applications which include sys/user.h, or any other non-standard
header file, should expect that any conceivable symbol might be used
therein.  FreeBSD makes no guarantees as to the namespace used by
non-standard interfaces.  (We don't want to be like certain other
environments where every symbol that might conceivably be accessible
to an application is obfuscated with multiple underscores.)

-GAWollman


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: namespace pollution with struct thread?

2001-11-12 Thread Julian Elischer

On the other hand we might conceivably be able to 
stop the export from the kernel of this struct type.


On Mon, 12 Nov 2001, Garrett Wollman wrote:

 On Mon, 12 Nov 2001 14:01:35 -0800, Steve Kargl [EMAIL PROTECTED] 
said:
 
  I WINE developer has suggested that this is namespace
  pollution on the part of FreeBSD, but he hasn't given
  any details to support what he means.
 
 Applications which include sys/user.h, or any other non-standard
 header file, should expect that any conceivable symbol might be used
 therein.  FreeBSD makes no guarantees as to the namespace used by
 non-standard interfaces.  (We don't want to be like certain other
 environments where every symbol that might conceivably be accessible
 to an application is obfuscated with multiple underscores.)
 
 -GAWollman
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-current in the body of the message
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: namespace pollution with struct thread?

2001-11-12 Thread John Baldwin


On 12-Nov-01 Julian Elischer wrote:
 On the other hand we might conceivably be able to 
 stop the export from the kernel of this struct type.

Not unless we stop exporting struct proc since each proc has an embedded thread.

 On Mon, 12 Nov 2001, Garrett Wollman wrote:
 
 On Mon, 12 Nov 2001 14:01:35 -0800, Steve Kargl
 [EMAIL PROTECTED] said:
 
  I WINE developer has suggested that this is namespace
  pollution on the part of FreeBSD, but he hasn't given
  any details to support what he means.
 
 Applications which include sys/user.h, or any other non-standard
 header file, should expect that any conceivable symbol might be used
 therein.  FreeBSD makes no guarantees as to the namespace used by
 non-standard interfaces.  (We don't want to be like certain other
 environments where every symbol that might conceivably be accessible
 to an application is obfuscated with multiple underscores.)
 
 -GAWollman

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve!  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: namespace pollution with struct thread?

2001-11-12 Thread Steve Kargl

I can confirm that I can build wine and run it if
I put #ifdef _KERNEL ... #endif in sys/proc.h.  I was
uncertain about whether sys/user.h was a non-standard
header file.  I will probably relay Garrett's point
to the wine developers at some point.

steve


On Mon, Nov 12, 2001 at 03:50:16PM -0800, Julian Elischer wrote:
 On the other hand we might conceivably be able to 
 stop the export from the kernel of this struct type.
 
 
 On Mon, 12 Nov 2001, Garrett Wollman wrote:
 
  On Mon, 12 Nov 2001 14:01:35 -0800, Steve Kargl 
[EMAIL PROTECTED] said:
  
   I WINE developer has suggested that this is namespace
   pollution on the part of FreeBSD, but he hasn't given
   any details to support what he means.
  
  Applications which include sys/user.h, or any other non-standard
  header file, should expect that any conceivable symbol might be used
  therein.  FreeBSD makes no guarantees as to the namespace used by
  non-standard interfaces.  (We don't want to be like certain other
  environments where every symbol that might conceivably be accessible
  to an application is obfuscated with multiple underscores.)
  
  -GAWollman
  
  

-- 
Steve

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message