Date: Mon, 15 Mar 2010 11:13:38 -0400 From: John Baldwin <jhb@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: unixmania@gmail.com, ed@80386.nl, src-committers@freebsd.org, svn-src-all@freebsd.org, nwhitehorn@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r205014 - in head: . sys/amd64/amd64 sys/amd64/conf sys/amd64/include sys/amd64/linux32 sys/compat/freebsd32 sys/compat/ia32 sys/conf sys/fs/procfs sys/ia64/conf sys/ia64/ia64 sys/ia64/... Message-ID: <201003151113.38968.jhb@freebsd.org> In-Reply-To: <20100313.121932.997044077387131740.imp@bsdimp.com> References: <20100313090844.GV8200@hoeg.nl> <20100313170725.GW8200@hoeg.nl> <20100313.121932.997044077387131740.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 13 March 2010 02:19:32 pm M. Warner Losh wrote: > In message: <20100313170725.GW8200@hoeg.nl> > > Ed Schouten <ed@80386.nl> writes: > : * M. Warner Losh <imp@bsdimp.com> wrote: > : > that sounds like a good idea. But it isn't as simple as changing all > : > the COMPAT_FREEBSDX in the .c code. There's also hooks in the syscall > : > glue generation that would be affected. > : > : Hmmm... Indeed. > : > : I thought a bit more about this and I realized it would be better if we > : wouldn't use a FreeBSD major number for this, but the actual > : __FreeBSD_version. > > Hmmm, that might be harder. The problem is that when I want to run a > program from FreeBSD 3.0, I may need an interface that was in 3.0, but > was removed prior to 5.0 shipping. This means the kernel needs the > COMPAT_FREEBSD4 option right now to work. So things are kind of > confusing. This isn't completely theoretical. Old (<= 4.x) i386 binaries use the foosys() methods for SYSV IPC (e.g. msgsys()) rather than msgget, msgctl, etc., so this is a case that would have to be correctly handled by any new organization of these options. I do think it makes the most sense to have the setting be the oldest major rev, and I also think that using __FreeBSD_version values rather than major versions would be too fine-grained (not very user- friendly). It would also enforce the rule of mandating COMPAT_FREEBSD4 implying COMPAT_FREEBSD5, etc. It just means you can't try to build a stripped kernel that only includes FreeBSD4 support without including FreeBSD5 (which is a way to solve Warner's problem). Trying to enumerate "ranges" of supported compat releases would be too confusing and error-prone I think. Also, the syscall generation bit would not be that hard. You would just replace the code that generates '#ifdef COMPAT_FREEBSD4' with '#if FREEBSD_COMPAT_VERSION <= 4'. Of course, you would probably want to special case version 0 so that you could remove all compat support if the option isn't defined, so it would maybe have to be '#if define(FREEBSD_COMPAT_VERSION) && FREEBSD_COMPAT_VERSION <= 4'. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201003151113.38968.jhb>