On Thu, Jul 10, 2008 at 4:37 PM, David O'Brien <[EMAIL PROTECTED]> wrote: > On Thu, Jul 10, 2008 at 10:35:35AM -0700, Peter Wemm wrote: >> On Thu, Jul 10, 2008 at 9:35 AM, David E. O'Brien <[EMAIL PROTECTED]> wrote: >> > Author: obrien >> > Date: Thu Jul 10 16:35:57 2008 >> > New Revision: 180431 >> > URL: http://svn.freebsd.org/changeset/base/180431 >> > >> > Log: >> > Allow 'elf_file_t' to be used in a wider scope. >> > >> > Modified: >> > head/sys/kern/link_elf.c >> > head/sys/sys/link_elf.h >> >> This really was intentional. elf_file_t was supposed to be opaque and >> changeable. What do you need this for? > > Juniper needs to be able to call functions in the loadable modules before > the modules are actually linked into the kernel. This will be used to > call platform specific initialization functions early in the bootup > process. Will also need un-static link_elf_preload_parse_symbols, > parse_dynamic, symbol_name, link_elf_lookup_symbol, > link_elf_symbol_values.
I think you should leave it in Juniper's tree for a tad longer: ../../../kern/link_elf_obj.c:88: error: redefinition of 'struct elf_file' ../../../kern/link_elf_obj.c:119: error: redefinition of typedef 'elf_file_t' ../../../sys/link_elf.h:133: error: previous declaration of 'elf_file_t' was here There is a better way to do what you want though. You're using loader still, right? I have old code kicking around that allowed linking the kernel against a hal module properly. I did this to support linking the kernel against an apic / smp / apic / 8259 module and combinations. -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert Sewell _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
