Denys Vlasenko wrote:
>More importantly, people aren't typically type "busybox foo ..." -
>they rely on symlinked names and they just type "foo ...".
>And there is no "rwok" symlink. "rwok -rf /" won't work.
I prefer standalone shell mode, which avoids the need for all the
symlinks. In that case
On 04/21/2016 06:02 PM, Denys Vlasenko wrote:
On Wed, Apr 20, 2016 at 5:15 PM, Ron Yorston wrote:
Denys Vlasenko wrote:
Downside: "busybox BOGUSNAME" has a small chance of actually working
as some applet, if hash(BOGUSNAME) is matching something.
Whatever you do, don't run
On Wed, Apr 20, 2016 at 5:15 PM, Ron Yorston wrote:
> Denys Vlasenko wrote:
>>Downside: "busybox BOGUSNAME" has a small chance of actually working
>>as some applet, if hash(BOGUSNAME) is matching something.
>
> Whatever you do, don't run 'busybox rwok -rf /'.
Exactly.
But that
Jody Bruchon wrote:
>It is definitely interesting. The problem from my perspective is that
>the potential performance drop is way too high. On platforms where 500
>bytes matter, chances are that CPU power is also very limited. This
>increases the fork cost when any BusyBox applet is invoked,
Denys Vlasenko wrote:
>Downside: "busybox BOGUSNAME" has a small chance of actually working
>as some applet, if hash(BOGUSNAME) is matching something.
Whatever you do, don't run 'busybox rwok -rf /'.
Ron
___
busybox mailing list
busybox@busybox.net
On Wed, Apr 20, 2016 at 1:03 PM, Denys Vlasenko
wrote:
> On Wed, Apr 20, 2016 at 12:55 PM, Guillermo Rodriguez Garcia
> wrote:
> >>> When strings are abbreviated the new find_applet_by_name() is about
> >>> 34% slower than currently. (All
On Wed, Apr 20, 2016 at 2:54 PM, Ron Yorston wrote:
> Denys Vlasenko wrote:
>>How about this version?
>
> Neat. The generated include file is much prettier and you managed to
> squeeze out a few more bytes.
>
> A couple of things:
>
>Since you've dropped the adjustment to the
On 2016-04-20 08:03, Denys Vlasenko wrote:
> On Wed, Apr 20, 2016 at 12:55 PM, Guillermo Rodriguez Garcia
> wrote:
When strings are abbreviated the new find_applet_by_name() is about
34% slower than currently. (All comparisons are for the default
Denys Vlasenko wrote:
>How about this version?
Neat. The generated include file is much prettier and you managed to
squeeze out a few more bytes.
A couple of things:
Since you've dropped the adjustment to the number of offsets you can
remove 2*KNOWN_APPNAME_OFFSETS from the size
On Wed, Apr 20, 2016 at 12:55 PM, Guillermo Rodriguez Garcia
wrote:
>>> When strings are abbreviated the new find_applet_by_name() is about
>>> 34% slower than currently. (All comparisons are for the default
>>> configuration.)
>>
>> Crazy :D
>
> Is this really worth
2016-04-20 12:46 GMT+02:00 Denys Vlasenko :
> On Tue, Apr 19, 2016 at 2:15 PM, Ron Yorston wrote:
>> The string of applet names seems ripe for compression: it has a limited
>> range of characters and many common substrings. If the compression is
>> too
On Tue, Apr 19, 2016 at 2:15 PM, Ron Yorston wrote:
> The string of applet names seems ripe for compression: it has a limited
> range of characters and many common substrings. If the compression is
> too aggressive, though, the code required to handle it causes bloat.
>
>
The string of applet names seems ripe for compression: it has a limited
range of characters and many common substrings. If the compression is
too aggressive, though, the code required to handle it causes bloat.
Recursively replace common pairs of characters with a character having
its top bit
13 matches
Mail list logo