Re: namespace pollution with struct thread?
On 14 Nov 2001, Dag-Erling Smorgrav wrote: > One other thing worth pointing out is that there is no reason for > to include . 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, currently pulls in a > lot of other headers such as and that are > needed only because depends on them. These are needed for too (except includes them itself). The struct mtx in 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
Re: namespace pollution with struct thread?
On 14 Nov 2001, Dag-Erling Smorgrav wrote: > > One other thing worth pointing out is that there is no reason for > to include . It just needs to declare struct > proc as an opaque structure. Also, currently pulls in a > lot of other headers such as and that are > needed only because 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?
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 . One other thing worth pointing out is that there is no reason for to include . It just needs to declare struct proc as an opaque structure. Also, currently pulls in a lot of other headers such as and that are needed only because 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: struct thread
No, ive removed the include, and it compiled and runs very good. Jan On Tue, 2001-11-13 at 22:45, Julian Elischer wrote: > do they need user.h? > > > On 13 Nov 2001, Jan Stocker wrote: > > > Wine includes sys/user.h which includes sys/proc.h. The configure skript > > determines the existence, but it isnt really needed to compile Maybe > > other systems defines here some needful stuff which is included > > somewhere else in FreeBSD? > > > > Jan > > > > > > On Tue, 2001-11-13 at 21:32, Julian Elischer wrote: > > > The trouble is that proc.h is not supposed to be exporting anything to > > > userland.. (with the exception of hacks like 'ps' but they are a > > > special category. > > > > > > It is kernel internal definitions.. > > > > > > Why is wine including it? > > > If there is something in it that is needed by wine then we need to think > > > about why it needs a kernel internal definition, and maybe whether > > > we shouldn't move it somewhere else that IS exported.. > > > > > > > > > On Tue, 13 Nov 2001, Jan Stocker wrote: > > > > > > > FYI: Ive posted an article to comp.emulators.ms-windows.wine about compiling > > > > errors for wine. This is caused by an redefinition of "struct thread". This > > > > is the state at present: > > > > > > > > > > > > > > > > From: [EMAIL PROTECTED] (Steven G. Kargl) > > > > Subject: Re: Compile errors with FreeBSD 5.0 > > > > Newsgroups: comp.emulators.ms-windows.wine > > > > > > > > In article <[EMAIL PROTECTED]>, > > > > Ove Kaaven <[EMAIL PROTECTED]> writes: > > > > > > > > > >> Jan Stocker wrote: > > > > >> > Hi, > > > > >> > the current version of FreeBSD (5.0) has a common header which defines > > > > >> > struct thread, so there will be an redefinition and nothing works. I > > > > >> > think you shall rename your stuff from thread.h to something like > > > > wine_thre > > > > >> > to get out of this trouble. > > > > > > > > > > I'd rather say that the problem is FreeBSD. System headers should not > > > > > pollute the namespace of applicatio. The glibc headers take great care to > > > > > avoid polluting the namespace, but FreeBSD is starting to look like it > > > > > thinks that it can define any common name, and if there's a collision > > > > > because of that carelessness, they tell all the apps to rename their > > > > > symbols, instead of fixing the OS. > > > > > > > > Can you elaborate? The application is pulling in the system > > > > header sys/proc.h where struct thread is defined. If an > > > > application purposely pulls in a system header file, how can > > > > the system header pollute the namespace of the application > > > > when the applications requests the information in that header? > > > > > > > > > > > > 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 > > > > > > > > > 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: struct thread
do they need user.h? On 13 Nov 2001, Jan Stocker wrote: > Wine includes sys/user.h which includes sys/proc.h. The configure skript > determines the existence, but it isnt really needed to compile Maybe > other systems defines here some needful stuff which is included > somewhere else in FreeBSD? > > Jan > > > On Tue, 2001-11-13 at 21:32, Julian Elischer wrote: > > The trouble is that proc.h is not supposed to be exporting anything to > > userland.. (with the exception of hacks like 'ps' but they are a > > special category. > > > > It is kernel internal definitions.. > > > > Why is wine including it? > > If there is something in it that is needed by wine then we need to think > > about why it needs a kernel internal definition, and maybe whether > > we shouldn't move it somewhere else that IS exported.. > > > > > > On Tue, 13 Nov 2001, Jan Stocker wrote: > > > > > FYI: Ive posted an article to comp.emulators.ms-windows.wine about compiling > > > errors for wine. This is caused by an redefinition of "struct thread". This > > > is the state at present: > > > > > > > > > > > > From: [EMAIL PROTECTED] (Steven G. Kargl) > > > Subject: Re: Compile errors with FreeBSD 5.0 > > > Newsgroups: comp.emulators.ms-windows.wine > > > > > > In article <[EMAIL PROTECTED]>, > > > Ove Kaaven <[EMAIL PROTECTED]> writes: > > > > > > > >> Jan Stocker wrote: > > > >> > Hi, > > > >> > the current version of FreeBSD (5.0) has a common header which defines > > > >> > struct thread, so there will be an redefinition and nothing works. I > > > >> > think you shall rename your stuff from thread.h to something like > > > wine_thre > > > >> > to get out of this trouble. > > > > > > > > I'd rather say that the problem is FreeBSD. System headers should not > > > > pollute the namespace of applicatio. The glibc headers take great care to > > > > avoid polluting the namespace, but FreeBSD is starting to look like it > > > > thinks that it can define any common name, and if there's a collision > > > > because of that carelessness, they tell all the apps to rename their > > > > symbols, instead of fixing the OS. > > > > > > Can you elaborate? The application is pulling in the system > > > header sys/proc.h where struct thread is defined. If an > > > application purposely pulls in a system header file, how can > > > the system header pollute the namespace of the application > > > when the applications requests the information in that header? > > > > > > > > > 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 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: struct thread
Wine includes sys/user.h which includes sys/proc.h. The configure skript determines the existence, but it isnt really needed to compile Maybe other systems defines here some needful stuff which is included somewhere else in FreeBSD? Jan On Tue, 2001-11-13 at 21:32, Julian Elischer wrote: > The trouble is that proc.h is not supposed to be exporting anything to > userland.. (with the exception of hacks like 'ps' but they are a > special category. > > It is kernel internal definitions.. > > Why is wine including it? > If there is something in it that is needed by wine then we need to think > about why it needs a kernel internal definition, and maybe whether > we shouldn't move it somewhere else that IS exported.. > > > On Tue, 13 Nov 2001, Jan Stocker wrote: > > > FYI: Ive posted an article to comp.emulators.ms-windows.wine about compiling > > errors for wine. This is caused by an redefinition of "struct thread". This > > is the state at present: > > > > > > > > From: [EMAIL PROTECTED] (Steven G. Kargl) > > Subject: Re: Compile errors with FreeBSD 5.0 > > Newsgroups: comp.emulators.ms-windows.wine > > > > In article <[EMAIL PROTECTED]>, > > Ove Kaaven <[EMAIL PROTECTED]> writes: > > > > > >> Jan Stocker wrote: > > >> > Hi, > > >> > the current version of FreeBSD (5.0) has a common header which defines > > >> > struct thread, so there will be an redefinition and nothing works. I > > >> > think you shall rename your stuff from thread.h to something like > > wine_thre > > >> > to get out of this trouble. > > > > > > I'd rather say that the problem is FreeBSD. System headers should not > > > pollute the namespace of applicatio. The glibc headers take great care to > > > avoid polluting the namespace, but FreeBSD is starting to look like it > > > thinks that it can define any common name, and if there's a collision > > > because of that carelessness, they tell all the apps to rename their > > > symbols, instead of fixing the OS. > > > > Can you elaborate? The application is pulling in the system > > header sys/proc.h where struct thread is defined. If an > > application purposely pulls in a system header file, how can > > the system header pollute the namespace of the application > > when the applications requests the information in that header? > > > > > > 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: struct thread
The trouble is that proc.h is not supposed to be exporting anything to userland.. (with the exception of hacks like 'ps' but they are a special category. It is kernel internal definitions.. Why is wine including it? If there is something in it that is needed by wine then we need to think about why it needs a kernel internal definition, and maybe whether we shouldn't move it somewhere else that IS exported.. On Tue, 13 Nov 2001, Jan Stocker wrote: > FYI: Ive posted an article to comp.emulators.ms-windows.wine about compiling > errors for wine. This is caused by an redefinition of "struct thread". This > is the state at present: > > > > From: [EMAIL PROTECTED] (Steven G. Kargl) > Subject: Re: Compile errors with FreeBSD 5.0 > Newsgroups: comp.emulators.ms-windows.wine > > In article <[EMAIL PROTECTED]>, > Ove Kaaven <[EMAIL PROTECTED]> writes: > > > >> Jan Stocker wrote: > >> > Hi, > >> > the current version of FreeBSD (5.0) has a common header which defines > >> > struct thread, so there will be an redefinition and nothing works. I > >> > think you shall rename your stuff from thread.h to something like > wine_thre > >> > to get out of this trouble. > > > > I'd rather say that the problem is FreeBSD. System headers should not > > pollute the namespace of applicatio. The glibc headers take great care to > > avoid polluting the namespace, but FreeBSD is starting to look like it > > thinks that it can define any common name, and if there's a collision > > because of that carelessness, they tell all the apps to rename their > > symbols, instead of fixing the OS. > > Can you elaborate? The application is pulling in the system > header sys/proc.h where struct thread is defined. If an > application purposely pulls in a system header file, how can > the system header pollute the namespace of the application > when the applications requests the information in that header? > > > 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
struct thread
FYI: Ive posted an article to comp.emulators.ms-windows.wine about compiling errors for wine. This is caused by an redefinition of "struct thread". This is the state at present: From: [EMAIL PROTECTED] (Steven G. Kargl) Subject: Re: Compile errors with FreeBSD 5.0 Newsgroups: comp.emulators.ms-windows.wine In article <[EMAIL PROTECTED]>, Ove Kaaven <[EMAIL PROTECTED]> writes: > >> Jan Stocker wrote: >> > Hi, >> > the current version of FreeBSD (5.0) has a common header which defines >> > struct thread, so there will be an redefinition and nothing works. I >> > think you shall rename your stuff from thread.h to something like wine_thre >> > to get out of this trouble. > > I'd rather say that the problem is FreeBSD. System headers should not > pollute the namespace of applicatio. The glibc headers take great care to > avoid polluting the namespace, but FreeBSD is starting to look like it > thinks that it can define any common name, and if there's a collision > because of that carelessness, they tell all the apps to rename their > symbols, instead of fixing the OS. Can you elaborate? The application is pulling in the system header sys/proc.h where struct thread is defined. If an application purposely pulls in a system header file, how can the system header pollute the namespace of the application when the applications requests the information in that header? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: namespace pollution with struct thread?
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: > > > <<[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 , 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
Re: namespace pollution with struct thread?
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: > >> <> <[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 , 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?
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: > < >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 , 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
namespace pollution with struct thread?
< 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 , 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
namespace pollution with struct thread?
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
