Date: Tue, 12 Jan 1999 22:28:35 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dcs@newsguy.com (Daniel C. Sobral) Cc: dervish@bantu.cl.msu.edu, dillon@apollo.backplane.com, hackers@FreeBSD.ORG Subject: Re: What are the advantages of ELF kernels? Message-ID: <199901122228.PAA06757@usr09.primenet.com> In-Reply-To: <369B125D.F487B9@newsguy.com> from "Daniel C. Sobral" at Jan 12, 99 06:14:05 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I might be misleading here, but I'd think the Number One reason for > changing to Elf is the lack of availability of binutils for a.out. > Support for a.out has been abandoned in binutils (gcc tools). So, it > seriously impacted on FreeBSD's ability to upgrade the compiler > toolchain. > > As for the specifics on how elf is so much better than a.out, I > usually heard most arguments coming from Terry. :-) It's better because it enables future work which would otherwise be impossible. I don't buy the shared library arguments, since mmap is mmap, and the semantics of an executable page aren't determined by the file name the thing is mapped from. The one good thing about the shared library semantic changes is that it should be possible to use a Motif distribution for Solaris or Linux on FreeBSD, assuming that you fix FreeBSD to conform to the Solaris libc or Linux libc calling conventions, such that a Motif depending on one or the other can actually link against a FreeBSD libc (the Solaris one fails because they changed function names instead of introducing binary incompatabilities to support 64bit off_t, etc.). It's also a pity that ELF objects generated on a 3.0 system won't be usable on a 3.1 (or later, if things go as slow as they have been, lately) system, since binutils 2.9.1 made a gratuitous change in the object file layout. Too bad FreeBSD didn't go to 2.9.1 and skip over the bad format entirely, but whatever. For the most part, ELF buys you multiple sections. Multiple sections buy you the ability to apply semantics to sections based on their names, or on associate attribute bits. One of many examples is that you could put all of the device probe code into a specific section name, and once you probed the devices at boot time, discard and reclaim that memory which is currently lost. Another example is that you could attribute the code in the paging path as "non-pageable", and allow the entire rest of the kernel to be paged in and out. This would let you do what "eBSD" (BSDI's "embedded BSD") does: run in 2M or less of real memory. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901122228.PAA06757>