Re: Patches for FreeBSD 5.x compilation
Steve Kargl <sgk(a)troutmask.apl.washington.edu> writes:
FreeBSD isn't polluting the namespace. <sys/user.h> is a a non-standard header file.
It's still made available to applications, and there is really no reason for exporting internal kernel names this way. At least it could be renamed or put inside #ifdef _KERNEL. The alternative is of course to avoid sys/user.h, or play with #defines on the Wine side; but prefixing our structures with wine_ is not a solution. -- Alexandre Julliard julliard(a)winehq.com
On Mon, Nov 19, 2001 at 10:52:24AM -0800, Alexandre Julliard wrote:
Steve Kargl <sgk(a)troutmask.apl.washington.edu> writes:
FreeBSD isn't polluting the namespace. <sys/user.h> is a a non-standard header file.
It's still made available to applications, and there is really no reason for exporting internal kernel names this way. At least it could be renamed or put inside #ifdef _KERNEL.
The alternative is of course to avoid sys/user.h, or play with #defines on the Wine side; but prefixing our structures with wine_ is not a solution.
What does wine need from <sys/user.h>? I've deleted inclusion of that header in server/context_i386.c, and wine builds and runs on FreeBSD 5.x. I haven't tested this on earlier versions of FreeBSD, and of course, I haven't tested this on other OS's. I recall that you're not fond of OS specific #ifdefs. #ifdef HAVE_SYS_USER_H # ifndef __FreeBSD__ # include <sys/user.h> # endif #endif Note, I've also posted to the FreeBSD-current mailing list about this conflict. Some developers have suggested the #ifdef _KERNEL protection you mention, and I suspect that this will be implemented at some point in the future. The stumbling block is that certain system utilities (gdb, ps, ptrace, etc.) need access to struct proc, which uses struct thread. Until these utilities are updated, I doubt the #ifdef _KERNEL will be used. I suspect that most people build wine from the FreeBSD Ports Collection. Perhaps, it is best to let the FreeBSD porters worry about this problem until FreeBSD 5.x settles down. -- Steve
On Mon, 19 Nov 2001, Steve Kargl wrote: [...]
What does wine need from <sys/user.h>?
I had a look at it on Linux and it is needed for the DR_OFFSET macro (line 80 and others). We define DR_OFFSET as: #define DR_OFFSET(dr) ((int)((((struct user *)0)->u_debugreg) + (dr))) And 'struct user' is defined in 'sys/user.h'. So without this #include we are 'dereferencing pointer to incomplete type'. But actually this code is in a '#ifdef linux' so it is the #include <sys/user.h> that should be moved in the same #ifdef. Just like the corresponding FreeBSD '#include <machine/reg.h>'! Hmm... sending a patch. I guess that one day Alexandre is going to argue that Linux should stop polluting the namespace with 'struct user'... Actually something similar also happened not very long ago with 'struct option', another good struct name to put in a system header! [...]
Note, I've also posted to the FreeBSD-current mailing list about this conflict. Some developers have suggested the #ifdef _KERNEL protection you mention, and I suspect that this will be implemented at some point in the future. The stumbling block is that certain system utilities (gdb, ps, ptrace, etc.) need access to struct proc, which uses struct thread. Until these utilities are updated, I doubt the #ifdef _KERNEL will be used.
That's why I initially proposed to change Wine: it's unrealistic to expect FreeBSD or any other OS to change their system headers... at least in any reasonable time frame. Plus it means that Wine would not work on such platforms.
I suspect that most people build wine from the FreeBSD Ports Collection. Perhaps, it is best to let the FreeBSD porters worry about this problem until FreeBSD 5.x settles down.
I would like Wine to compile out of the box on more platforms. People seem to think that Wine is a 'Linux-only' thing and leaving this kind of problem in the main tree only reinforces this perception. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Any sufficiently advanced bug is indistinguishable from a feature. -- from some indian guy
In article <Pine.LNX.4.21.0111191205010.11125-100000(a)amboise.dolphin> you wrote:
I guess that one day Alexandre is going to argue that Linux should stop polluting the namespace with 'struct user'... Actually something similar also happened not very long ago with 'struct option', another good struct name to put in a system header!
Linux doesn't have struct user. It uses a combinded struct task_struct for that what struct user & struct proc do on traditional Unix versions (minus uglinesses like u_error, u_off & co). The content of <sys/user.h> is provided by glibc just for a number of broken userspace apps like e.g. gdb. Christoph P.S. Yes, I really wonder why gbd can't use a private include.. -- Of course it doesn't work. We've performed a software upgrade.
In article <20011119114247.B56821(a)troutmask.apl.washington.edu> you wrote:
Note, I've also posted to the FreeBSD-current mailing list about this conflict. Some developers have suggested the #ifdef _KERNEL protection you mention, and I suspect that this will be implemented at some point in the future. The stumbling block is that certain system utilities (gdb, ps, ptrace, etc.) need access to struct proc, which uses struct thread. Until these utilities are updated, I doubt the #ifdef _KERNEL will be used.
SVR4.2MP/SVR5 uses _KMEMUSER for such stuff, I think it's the only halfway sane method to allow this access to kernel internals. In fact sharing structs directly between kernel and userspace should just die, die, die... Christoph -- Whip me. Beat me. Make me maintain AIX.
participants (4)
-
Alexandre Julliard -
Christoph Hellwig -
Francois Gouget -
Steve Kargl