Date: Thu, 27 Jul 95 13:46:03 MDT From: terry@cs.weber.edu (Terry Lambert) To: wollman@halloran-eldar.lcs.mit.edu (Garrett Wollman) Cc: esser@zpr.uni-koeln.de, current@freebsd.org Subject: Re: ls_length in struct linker_set Message-ID: <9507271946.AA13760@cs.weber.edu> In-Reply-To: <9507271754.AA10540@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Jul 27, 95 01:54:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Consider that most of the items that get "linker sets" have manifest > > constant kernel options to get them in in the first place. > > The entire intent of my work in this area was to ELIMINATE the > manifest constants in the first place. It should be possible to add a > new static filesystem to a kernel simply by dropping in an object > module, with no recompilation necessary. Then you need to fix i386/i386/autoconf.c; I've made a healthy start in this direction. > > Then consider that you might have a non-self-hosted porting environment > > that doesn't support linker sets. 8-). > > Using whose linker? I considered this question for all of five > minutes, and concluded that it was not worth any more thought, since > anything that we do with these things can be trivially implemented > using C++ constructors, and any reasonable build environment will > provide some facility for making C++ work. IBM's AIX linker on the Motorolla Ultra PPC 604. And without C++, a linker that supports C++ mechanisms is relatively useless (unless you happen to know the magic incantations for it). Or the DEC OSF/1 linker on the Alpha 21066 box. Because even with a GNU build environment, the GNU linker fails to operate correctly. It's a porting issue. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9507271946.AA13760>