Re: Beware of modules.

On Thu, Jan 14, 1999 at 06:23:06AM +0100, Olivier Galibert wrote: With respect, I suggest that you re-examine the ABI, and especially how trampolines and shared loading works. Linux isnt a reference platform for PIC code, SVR4 is. If Linux handles trampolines incorrectly, thats Linux's problem. There is NO reason that it should be slower than other code. If this was true, hello.c would be slow, every single X application (not to mention the X server) would be slow etc, as they all used shared libraries (libc.so, libX11.so etc). All of those shared libraries are compiled in PIC code. Do you REALLY think that PIC is that bad? Register spilling in a compiler, and the misuse of registers, is not an "order of magnitude" difference. Quite often you have to examine individual instruction cycles to get down to microsecond timing differences. Its not that big of a deal, and if trampolines are done properly, there is a one-time overhead on load. Thereafter, the addresses are bound. Problem solved. Considering how I envisage them being built, this wont be a problem. The modules live in the architecture dependant directory, which has the XEmacs version number in it. For user-installed modules in the site-modules directory, there is an explicit check for the version, and the module wont load if the versions mis-match. Please, dont assume that a new feature requires NO work and discipline on behalf of the people who use it. And I already anticipated this problem, which is why each module is stamped with the module loading version (i.e. the version of the module loading technology itself, not the XEmacs version). At any time that incompatible changes are introduced into XEmacs, all that is required to bump that version, and everything that came before it won't load. Simple, but very effective. Modules are by their very definition architecture dependant, and as I said above, the architecture has the XEMcs version as a function of it. Aside from that, there is still a good chance that modules will load from version to version, and this will remain true unless there are very fundamnetal changes within XEmacs, which is what the internal module version number is for. There is NO argument that modules will tkae a little bit of extra care if you really want to share multiple versions of XEMacs, but lets face it, the only people that do that in the REAL world are XEmacs developers, and they can cope with the small overhead easily. Eh? I dont understand this objection at all. Why do you want to undump something that is dynamic? Please expand on this more so that I can understand the objection / limitation. Sir, I understand modern VM's very well. I have helped write one of the most sophisticated and modern ones around (except for MPE - thats still the most kick-ass OS I have ever seen). Yes, the VM will swap out pages when it needs to, but there's the rub, do we REALLY want to force the VM into that state if we dont need to? Netscape does the Wrong Thing by having such a monolithic binary, and XEmacs is headed the same way. The entire UNIX philosophy is to keep things small, and grow on demand, not start huge and discard on demand. -- J. Kean Johnston | "If equal affection cannot be, Engineer, SPG | let the more loving one be me" - W.H. Auden Santa Cruz, CA +---------------------------------------------------------- Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj(a)sco.com