[haiku-commits] Re: r39439 - in haiku/branches/developer/bonefish/weak-symbols/src/system/runtime_loader: . arch/m68k arch/ppc arch/x86
- From: François Revol <revol@xxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Tue, 16 Nov 2010 12:37:57 +0100
Le 16 nov. 2010 à 12:20, Stephan Aßmus a écrit :
>> 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.
I know he has good reasons to do it, it was the caching I wondered, specially
having lots of unrelated caches that might compete for RAM.
>> 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.
Well I do hope that at least partly this effort might help optimizing the other
ports as well, or introduce features (think DSP based mp3 decoder and mixer,
but I'm dreaming, that might entice people to do alike on other archs with hw
accelerated media nodes).
Also, keep in mind some other targets also have constrained RAM (ARM...), that
are more likely to be used in the future.
François.
Other related posts:
