FreeBSD Release Engineering team’s Scott Long has written a bootloader front-end script that allows one to enable/disable acpi, boot single users, etc. Elsewhere, Matthew N. Dodd has implemented per-executable ELF prebinding in FreeBSD-current. Initial performance measurements are very encouraging. Relocatable objects (executables and libraries) contain elements that require relocation before they are usable. By ‘prebinding’, much of this work can be done beforehand and speed up the actual relocation process. As a result, apps like KDE and other library happy executables take a little less time to load.
New Bootloader, Preliminary ELF Prebinding Patches for FreeBSD
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
I wish the default boot manager would recognize NTFS partitions and have them show up as “NT Windows” or just “Windows” like FAT partitions do, instead of “???”. If I knew the relevant section of the code, I might even try to submit a patch, but I am under the impression (I have not researched it though) that the relevant section is either in Forth or Assembly.
Ah. Sorry for replying to myself – here is the relevant code:
ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/sys/boot/i38…
(at the very bottom)
“As a result, apps like KDE and other library happy executables take a little less time to load.”
How much is a “little less”?
I looked at doing similar a while back, but I think the issue is that the bootloader must fit in 512 bytes – not much room for manoeuvre.
–Jon
prebinding sounds an aweful lot like the prelinking work Drepper (of RH fame) has been doing in glibc/binutils/kernel – I’m surprised to see the FreeBSD guys even care about this because it’s not really a “server thing” and it’s a massive job to relink everything when you update just one program (that being said I haven’t looked at the FBSD implementation – they might have a clever way around that I haven’t noticed).
Things are really starting to hot up in the old development pool. It will be really choice once FreeBSD 5.2 is released, which apparently will have a completed libpthreads library, heaps of bug fixes and from what I have heard, will be either equal or faster than the 4.x series.
hmm…its seems FreeBSD’s prebinding happens automagiclly after you build something from source (like in ms windows), while prelinking in Linux is done by running a “prelink” tool :/
that kinda sucks…
A reason the development team could be looking into this is the recent nslookup changes, as that requires heavily on having dynamic loadable libraries in the base system, they are perhaps going to do something like NetBSD has already done and build their base using shared libraries instead of being statically linked.
Not only will this save space, but allow FreeBSD to take full advantage of the new nslookup changes, specifically being able to lookup passwd entries from a LDAP database.
I recommend checking out the mailing.freebsd.current group on groups.google.com for more information on this.
In theory, you only have to relink everything when you run out of address space to assign, which is significantly less often then installing apps in general. However, using a method like that tends to fragment your address space a lot (everytime you remove an app, you leave a hole in the address space). This is another reason we need 64-bit CPUs, so we can prelink everything without worrying about relinking every time.
@CoronaLVR — MS Windows doesn’t prelink. In fact, it uses a much more primitive technology for shared libraries. Windows DLL’s are assigned generally not position independent. They are assigned a virtual address when they are built. At load time, if this virtual address is not available, they are relocated to run at an available address. However, this relocation prevents the DLL from being shared, and it becomes equivilent to static linking. In comparison, ELF shared libraries are compiled as position independent code, which means they can be loaded at any virtual address and still shared. However, when an ELF shared library is loaded (at any address) two tables, the PLT and the GOT (contains the addresses of global procedures and data) must be relocated. After the relocation, only these two data structures become unshared. In C++ libraries, the PLT can become huge, with 20,000+ entries in the case of Qt, which is where prelinking comes into play.
What Rayiner is talking about with DLLs is what Microsoft refer to as “rebasing”.
For those who are interested, linking was already heavily optimized years ago with the introduction of lazy linkage. In this scheme, rather than the GOT being rewritten at program startup, the compiler generates a set of jumps to the PLT (procedure linkage table). The PLT in turn is a set of code blocks, one for each function being linked, that call into the linker to actually perform the link edit and then rewrite the GOT. That means the link is put off until the function is actually used.
Unfortunately for various reasons that doesn’t work terribly well for C++ apps, and they tend to need lots of symbols being linked at startup time. Prelinking helps solve this. As an example of what a difference it can make, link time for Konqueror went from half a second to 0.001 of a second iirc with prelinking enabled – when it takes over half a second for Konq to even start execution this can be a significant saving.
However, the majority of apps on Linux are written in C unless you use KDE, so it makes less difference to those programs. It also makes little difference to Mozilla, as that doesn’t link many external libs (they are mostly loaded on demand via XPCOM).
So really this feature is primarily to help out KDE users.
Yes, ofcourse you guys are right, windows does not prelink in the same way linux and FreeBSD do it, but the end result is the same, windows apps start fast.
It’s written in Forth
… doesn’t prelink at all. Most Win32 apps use very few libraries however compared to your typical Linux app, so it’s less of an issue.
They didnt change that part of the loader. If you look at the source and in /boot in current, you’ll see 4 programs, boot[0-2] and loader. boot0 is the mbr loader. This is what lets you choose an active partition to load, but it has to fit into 512 bytes, so all it does in some cases is load the active partition or ask you one. This is where your NTFS problem lies. This is written in assembly. /usr/src/sys/boot/i386/boot0/boot0.s boot0 is the next part you will see telling you your physical drives. If you use grub, you probably chainload to /boot/loader since this is the official method. You can normally disable acpi and go into single user mode through loader anyway, and do other things like load alternate kernels and modules. This is just something else for loader to read, letting users do this easier from what i understand
microsoft’s DLL linking technology has been a part of windows for over 10 years and now fleabsd is stealing it. way to go open source, steal all your ideas from microsoft, steal your gnomes, steal your start menus, steal your office programs
it is cool that freebsd has it first instead of linux i guess, but linux needs to catch up quickly. with enough dlls u could run a windows program on linux
Stupid trol…
It was my understanding that Windows does pre-relocation rather than pre-binding.
Regardless, aside from the initial shove from NetBSD and an overview on OS X, I’m making this stuff up as I go along.
So far I haven’t seen anyone using the same method I’m using, and my development code is diverging at high speed from the patch I posted to -current.
I recently bought mandrake 9.1 and i was wondering
if it had any Windows DLL and EXE support so i could
run windows programs in Mandrake or any other distribution for that matter..