Re: About the approximate applet sizes in menuconfig

[Denys Vlasenko]

On Thu, Jul 20, 2017 at 3:57 PM, Kang-Che Sung  wrote:
>> This would solve 2 problems.
>> 1. it is clear what the base is (Kang-Che Sung point 3 is valid)
>> 2. in future all claims like "save 200 Bytes (tested on MIPSxyz)" are off 
>> limits.
>>
> What do you mean by "beginning" when it comes to menuconfig interface?

Yep, I also did not have any good ideas where to put the explanation.

> And beside this, there're some more problem that I forgot to mention:
> 4. The sizes will definitely need to be updated somewhen to reflect the code
>changes, and I won't know how much maintenance burden will there be.
>Sure it can be automated (like size_single_applets.sh), but updating the
>Config.in files will probably make you crazy (sorry Denys Vlasenko).

size_single_applets.sh does emit a functioning set of sed
commands which automagically patch all sizes in all menu items.

I surely did not edit all 400 of them by hand :D

Now anyone is free to build on make_single_applets.sh / size_single_applets.sh
and teach it to also measure every option.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: About the approximate applet sizes in menuconfig

[Kang-Che Sung]

On Thu, Jul 20, 2017 at 8:22 PM, walter harms  wrote:
>
>
> Am 20.07.2017 12:17, schrieb Denys Vlasenko:
>> On Wed, Jul 19, 2017 at 6:38 PM, Kang-Che Sung  wrote:
>>> (https://git.busybox.net/busybox/commit/?id=4eed2c6c5092ed95b8ee6d994106c54a9fc6ed3e)
>>>
>>> I don't like this. I don't like these size info to be put on the titles
>>> of config options. A few reasons:
>>> * It can give a false impression that the size of the final busybox
>>>   binary is the size of these applets summed up, but it's actually not.
>>>   (Some code can share among applets)
>>> * The sizes are CPU architecture dependent.
>>
>> Sure, on a different arch, sizes would change, but "20k" applet is
>> still approximately 4 times larger than "5k" one.
>> that's useful information for the user.
>>
>
> to be korrekt we would need to test with every new compiler/-option more over
> nobody knows when this claim was made. It should be clear for every programmer
> "your milage may vary" is here in big letters.

I can assume the size is measured with the default compiler options with a
modern compiler -- nowadays building with GCC and building with Clang do not
bring so much size differences, but it's still good if we leave a note about
which compiler is used on measuring size.

And I used the word "about" for the "your mileage may vary" meaning.

>>> * How the sizes are measured are even unclear. So, does the size include
>>>   all optional features of the applet, or is it only the basic
>>>   functionality?
>>>
>>> If I were to mention the size in menuconfig, I would put in the help
>>> texts of the config options, rather than their titles. And be clear how
>>> the size is measured, for example:
>>>
>>>CONFIG_BINZIP2
>>>(Adds about 8.8kB on i686, for bzip2 decompression code)
>>>CONFIG_BZIP2
>>>(Adds about 18kB on i686, for bzip2 compression and decompression code)
>>
>> Can you automate this for 400 applets and ~600 options?
>
> I guess there is no need, what about a description in the beginig like
> "All sizes relate to i686, depending on your target arch this may differ"
> (replace i686 with anything you like)
>
> This would solve 2 problems.
> 1. it is clear what the base is (Kang-Che Sung point 3 is valid)
> 2. in future all claims like "save 200 Bytes (tested on MIPSxyz)" are off 
> limits.
>
What do you mean by "beginning" when it comes to menuconfig interface?

And beside this, there're some more problem that I forgot to mention:
4. The sizes will definitely need to be updated somewhen to reflect the code
   changes, and I won't know how much maintenance burden will there be.
   Sure it can be automated (like size_single_applets.sh), but updating the
   Config.in files will probably make you crazy (sorry Denys Vlasenko).
5. What to do if someone propose a new applet into busybox? He or she couldn't
   have the same environment to measure the size.

For my point no.4, how about this: Instead of putting the sizes in the
Config.in files or source code, make them in an external text file named
"size-ref.txt" (outside menuconfig). Then you can try any automate way to
update the file, or even allow users to measure themselves, with their own
environment.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: About the approximate applet sizes in menuconfig

[walter harms]

Am 20.07.2017 12:17, schrieb Denys Vlasenko:
> On Wed, Jul 19, 2017 at 6:38 PM, Kang-Che Sung  wrote:
>> (https://git.busybox.net/busybox/commit/?id=4eed2c6c5092ed95b8ee6d994106c54a9fc6ed3e)
>>
>> I don't like this. I don't like these size info to be put on the titles
>> of config options. A few reasons:
>> * It can give a false impression that the size of the final busybox
>>   binary is the size of these applets summed up, but it's actually not.
>>   (Some code can share among applets)
>> * The sizes are CPU architecture dependent.
> 
> Sure, on a different arch, sizes would change, but "20k" applet is
> still approximately 4 times larger than "5k" one.
> that's useful information for the user.
>

to be korrekt we would need to test with every new compiler/-option more over
nobody knows when this claim was made. It should be clear for every programmer
"your milage may vary" is here in big letters.


>> * How the sizes are measured are even unclear. So, does the size include
>>   all optional features of the applet, or is it only the basic
>>   functionality?
>>
>> If I were to mention the size in menuconfig, I would put in the help
>> texts of the config options, rather than their titles. And be clear how
>> the size is measured, for example:
>>
>>CONFIG_BINZIP2
>>(Adds about 8.8kB on i686, for bzip2 decompression code)
>>CONFIG_BZIP2
>>(Adds about 18kB on i686, for bzip2 compression and decompression code)
> 
> Can you automate this for 400 applets and ~600 options?
> 


I guess there is no need, what about a description in the beginig like
"All sizes relate to i686, depending on your target arch this may differ"
(replace i686 with anything you like)

This would solve 2 problems.
1. it is clear what the base is (Kang-Che Sung point 3 is valid)
2. in future all claims like "save 200 Bytes (tested on MIPSxyz)" are off 
limits.


re,
 wh


>> Or alternatively, don't mention the size at all.
> 
> The sizes are helping users see which applets are bigger.
> Without sizes, it was pure guesswork: if someone optimizes for size,
> he would semi-randomly choose what to "sacrifice".
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
> 
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: [PATCH] bootchartd: prevent premature stop by device mapper

[Denys Vlasenko]

Applied, thanks!

On Wed, Jul 19, 2017 at 9:08 PM, Uwe Geuder (Nomovok Ltd.)
 wrote:
>
> kernel thread kdmflush was recognized as display manager kdm, check for 
> string length
>
> Signed-off-by: Uwe Geuder (Nomovok Ltd.) 
> ---
>  init/bootchartd.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/init/bootchartd.c b/init/bootchartd.c
> index 92aaade0f..0c52785d1 100644
> --- a/init/bootchartd.c
> +++ b/init/bootchartd.c
> @@ -171,7 +171,8 @@ static int dump_procs(FILE *fp, int 
> look_for_login_process)
> p++;
> strchrnul(p, ')')[0] = '\0';
> /* Is it gdm, kdm or a getty? */
> -   if (((p[0] == 'g' || p[0] == 'k' || p[0] == 'x') && 
> p[1] == 'd' && p[2] == 'm')
> +   if (((p[0] == 'g' || p[0] == 'k' || p[0] == 'x')
> +   && p[1] == 'd' && p[2] == 'm' && p[3] 
> == '\0')
>  || strstr(p, "getty")
> ) {
> found_login_process = 1;
> --
> 2.12.3
>
> ___
> busybox mailing list
> busybox@busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: About the approximate applet sizes in menuconfig

[Denys Vlasenko]

On Wed, Jul 19, 2017 at 6:38 PM, Kang-Che Sung  wrote:
> (https://git.busybox.net/busybox/commit/?id=4eed2c6c5092ed95b8ee6d994106c54a9fc6ed3e)
>
> I don't like this. I don't like these size info to be put on the titles
> of config options. A few reasons:
> * It can give a false impression that the size of the final busybox
>   binary is the size of these applets summed up, but it's actually not.
>   (Some code can share among applets)
> * The sizes are CPU architecture dependent.

Sure, on a different arch, sizes would change, but "20k" applet is
still approximately 4 times larger than "5k" one.
that's useful information for the user.

> * How the sizes are measured are even unclear. So, does the size include
>   all optional features of the applet, or is it only the basic
>   functionality?
>
> If I were to mention the size in menuconfig, I would put in the help
> texts of the config options, rather than their titles. And be clear how
> the size is measured, for example:
>
>CONFIG_BINZIP2
>(Adds about 8.8kB on i686, for bzip2 decompression code)
>CONFIG_BZIP2
>(Adds about 18kB on i686, for bzip2 compression and decompression code)

Can you automate this for 400 applets and ~600 options?

> Or alternatively, don't mention the size at all.

The sizes are helping users see which applets are bigger.
Without sizes, it was pure guesswork: if someone optimizes for size,
he would semi-randomly choose what to "sacrifice".
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: acpid & detection of new input devices

[Lauri Kasanen]

Hi,

Big acpid seems to use inotify on /dev/input. Or perhaps you can set up
an udev rule that sends a signal to acpid.

- Lauri
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox