[haiku-commits] Re: r39439 - in haiku/branches/developer/bonefish/weak-symbols/src/system/runtime_loader: . arch/m68k arch/ppc arch/x86

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Tue, 16 Nov 2010 12:20:42 +0100

Am 16.11.2010 11:16, schrieb François Revol:

Le 16 nov. 2010 à 11:13, Stephan Aßmus a écrit :

Am 16.11.2010 00:15, schrieb François Revol:
Le 15 nov. 2010 à 22:12, ingo_weinhold@xxxxxx a écrit :
Implemented a simple caching mechanism for symbol resolutions during the image
relocation. The cache consists of an array the same size as the image's symbol
table. After looking up a referenced symbol we store its value in the cache so
that we don't have to look it up again.
Idea blantantly stolen from FreeBSD.

Hmm more caches, I suspect it's this caching inflation that made Haiku not able 
to boot anymore with 40MB as it used to ;-)

Don't know what other caches you have in mind, maybe the IOCache for CD-ROM 
media? That one is run-time enabled if there is enough memory at all. I am sure 
this one could be as well. I would be surprised if FreeBSD is unable to boot in 
40 MB, and that's where the idea is taken from. I for one highly appreciate 
Ingo's optimizations, and considering he is the one who improved the virtual 
memory system so much for low memory systems, he must be knowing what he is 
doing. :-)

Yeah I was just wondering about overkill features.

The feature is support for weak symbols. The optimization is to reduce the impact of supplying that feature. If you think weak symbols should not be supported in the first place, please speak up in the thread that Ingo specifically started to discuss this.

Still, I'd hope we could lower the bar further, I know of only one Atari Falcon 
with 256MB of RAM around, and I don't have it ;-)

Your porting efforts are admired, but personally I care about using Haiku, not the satisfaction to get it booting up to various states. I can assure you here and now that should you ever get Haiku to boot graphically on an Atari Falcon, you will not be able to actually use it, unless you also rewrite the whole app_server drawing backend. And even then I doubt it will actually be usable for what happens in the rest of the user land. I am all for efficient code, but at the same time, certain features assert certain level of computing powers in the underlying hardware. I don't really support the notion to strip stuff from Haiku in order to (hopefully) support the Atari Falcon port.

Best regards,
-Stephan


Other related posts: