svn commit: r284198 - head/bin/ls

[NGie Cooper]

On Mon, Jun 15, 2015 at 6:46 PM, Julian Elischer <julian at freebsd.org> wrote:
> On 6/15/15 1:34 PM, Garrett Cooper wrote:
>>
>> On Jun 14, 2015, at 20:53, Julian Elischer <julian at freebsd.org> wrote:
>>
>>> On 6/14/15 10:48 AM, Adrian Chadd wrote:
>>>>
>>>> On 13 June 2015 at 18:22, Craig Rodrigues <rodrigc at freebsd.org> wrote:
>>>>>
>>>>> On Sat, Jun 13, 2015 at 6:00 PM, Adrian Chadd <adrian at freebsd.org>
>>>>> wrote:
>>>>>>>
>>>>>>> I guarantee that no matter what you've worked on, there's
>>>>>>> approximately five orders of magnitude of shipping devices whose
>>>>>>> entire storage space can be measured in 1 digit megabytes. Each year.
>>>>>>
>>>>>> (And yes - there's an appreciable set of them for which freebsd boots,
>>>>>> runs and keeps running on them.0
>>>>>>
>>>>>> You can buy em too, some of them even under $60.
>>>>>
>>>>> Can FreeBSD now not run on these systems because of libxo?
>>>>
>>>> It's a tight squeeze as it is. Running in 8MB of flash (even if it's
>>>> compressed) is still an exercise in "what can you cut out."
>>>>
>>>> My point isn't that it isn't running because of libxo; my point is
>>>> that arguing about "embedded" involving "lots of storage" is woefully
>>>> incorrect and will continue to be until those gigabytes of storage are
>>>> available for a penny. Which yes, I'm guessing will happen in my
>>>> career - but it's also quite likely code bloat will continue to chase
>>>> that upward.
>>>
>>> do we have a WITHOUT_LIBXO option on sources?  I believe we should..
>>
>> +1. I would be more than happy to implement it by stubbing out the
>> majority of the macros to something less invasive, but it might be a bit
>> before I do that.
>> Thanks,
>
> but that wouldn't remove the bloat within the apps.. just make it use null
> calls.

That was the idea. Make it like "libnxo" or something, a dummy library
like libnetbsd with weak symbols that can be optimized away by the
compiler...