Bug 20572

Summary: cannot safely remove COMPAT_43 from the kernel config
Product: Base System Reporter: Darern Reed <darrenr>
Component: kernAssignee: Andre Oppermann <andre>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 5.0-CURRENT   
Hardware: Any   
OS: Any   

Description Darern Reed freebsd_committer freebsd_triage 2000-08-13 09:10:00 UTC 
	Creating and attempting to build a kernel config without the
COMPAT_43 option present leads to the kernel failling to build when it
reaches /sys/kern/kern_sig.c:
cc -c -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing
-prototypes -Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi  -no
stdinc -I- -I. -I../.. -I/usr/include  -D_KERNEL -include opt_global.h -elf  -mp
referred-stack-boundary=2  ../../kern/kern_sig.c
../../kern/kern_sig.c:359: warning: function declaration isn't a prototype
../../kern/kern_sig.c: In function `osigaction':
../../kern/kern_sig.c:367: dereferencing pointer to incomplete type
../../kern/kern_sig.c:367: dereferencing pointer to incomplete type
../../kern/kern_sig.c:369: dereferencing pointer to incomplete type
../../kern/kern_sig.c:370: dereferencing pointer to incomplete type
../../kern/kern_sig.c:372: dereferencing pointer to incomplete type
../../kern/kern_sig.c:379: dereferencing pointer to incomplete type
../../kern/kern_sig.c:384: dereferencing pointer to incomplete type
../../kern/kern_sig.c: At top level:
../../kern/kern_sig.c:532: warning: function declaration isn't a prototype
../../kern/kern_sig.c: In function `osigprocmask':     
../../kern/kern_sig.c:538: dereferencing pointer to incomplete type
../../kern/kern_sig.c:539: dereferencing pointer to incomplete type
../../kern/kern_sig.c: At top level:
../../kern/kern_sig.c:567: warning: function declaration isn't a prototype      
../../kern/kern_sig.c:721: warning: function declaration isn't a prototype      
../../kern/kern_sig.c: In function `osigsuspend':
../../kern/kern_sig.c:729: dereferencing pointer to incomplete type
*** Error code 1 (continuing)

How-To-Repeat: 
	Generate a kernel config without COMPAT_43 and attempt to compile it.
Comment 1 Sheldon Hearn freebsd_committer freebsd_triage 2000-08-14 11:30:07 UTC 
State Changed
From-To: open->closed

That's why the option is marked with "[KEEP THIS!]" in GENERIC and 
"You probably do NOT want to remove this as much current code still 
relies on the 4.3 emulation." in NOTES.
Comment 2 Darern Reed freebsd_committer freebsd_triage 2000-08-14 11:58:43 UTC 
State Changed
From-To: closed->open

This was prematurely closed by the person answering it as the problem has 
not been fixed.  If "COMPAT_43" is not optional then it needs to no longer 
be an option.  If it is to remain an option then compile problems which 
occur when it is excluded need to be fixed.  Until one of these two routes 
is taken, this PR should remain open.
Comment 3 Sheldon Hearn 2000-08-14 13:06:04 UTC 
On Mon, 14 Aug 2000 21:56:51 +1000, Darren Reed wrote:

> I think the email from Mike (just recently) explained the situation - there
> has been a "problem" created by changes to the signal code.

If that's all that's standing in the way of COMPAT_43 becoming
optional, then you should assign the PR to marcel, who'll probably have
it sorted out in short order.

I must admit, my impression was that this would take a lot of work to
fix and that it wasn't a simple case of correcting one area of the
kernel.

Ciao,
Sheldon.
Comment 4 Mike Pritchard 2000-08-14 13:17:18 UTC 
Since the message I replied to wasn't the one attached to this PR,
I'll briefly re-state my point, so that it makes it into the PR history:

It used to be possible to compile and run a kernel without having
COMPAT_43 defined.  The last major signal change broke this.
Someone was supposed to be working on resolving this, but I think
it fell through the cracks, since it has been quite a while
since that signal change.  I can try and dig up more info 
if anyone wants (I may still have some of the e-mail archived).

-Mike

On Mon, Aug 14, 2000 at 09:56:51PM +1000, Darren Reed wrote:
> I think the email from Mike (just recently) explained the situation - there
> has been a "problem" created by changes to the signal code.
> 
> In some email I received from Sheldon Hearn, sie wrote:
> > 
> > 
> > On Mon, 14 Aug 2000 04:01:00 MST, darrenr@FreeBSD.ORG wrote:
> > 
> > > Until one of these two routes is taken, this PR should remain open.
> > 
> > Darren, please decide which of the 3 options I outlined works best for
> > you.
> > 
> > Ciao,
> > Sheldon.
-- 
Mike Pritchard
mpp@FreeBSD.org or mpp@mppsystems.com
Comment 5 Sheldon Hearn freebsd_committer freebsd_triage 2000-08-14 13:29:57 UTC 
Responsible Changed
From-To: freebsd-bugs->marcel

Marcel, could you take a look at this, now that you're 
"back on board". 
? :-)
Comment 6 Andre Oppermann freebsd_committer freebsd_triage 2003-12-27 15:19:57 UTC 
State Changed
From-To: open->closed

This PR is idle for too long.  I can compile 5.2RC2-i386 
without COMPAT_43 in the kernel config.
Comment 7 Andre Oppermann freebsd_committer freebsd_triage 2003-12-27 15:19:57 UTC 
Responsible Changed
From-To: marcel->andre

This PR is idle for too long.  I can compile 5.2RC2-i386 
without COMPAT_43 in the kernel config.