public inbox for linux-8086@vger.kernel.org
 help / color / mirror / Atom feed
From: "Marc-F. LUCCA-DANIAU" <mfld.fr@gmail.com>
To: ELKS <Linux-8086@Vger.Kernel.Org>
Subject: Re: Condensing and re-coding programs to save space
Date: Mon, 27 Feb 2017 23:02:22 +0100	[thread overview]
Message-ID: <f3331a1c-4d89-024d-82b4-88ad60a3bf2b@gmail.com> (raw)
In-Reply-To: <a2dc19af-7fba-5e2b-7781-752c5c0700c8@jodybruchon.com>

The unit tests for networking that I grouped in /elkscmd/test should not 
be included in the default images (because "test"...), and would be 
removed in next commits to make room. But we should also provide a more 
convenient way to customize the image, for a developer to be able to 
quickly add them back when doing non-regression testing.

Today we have to modify the Makefile to include / exclude a program, 5 
different targets for partial / full images, multiplied by the available 
image formats. Plus now a build_hd_image script that is not consistent 
(and IMHO, poorly designed as it unpacks an existing image to build 
another one, in place of building it directly).

Would be far better to follow the Buildroot / Busybox way, and to select 
the applets to be installed on the target in a single location. We 
already have a quite nice kernel configuration tool, why not using it 
for that selection and the choice of the image format ?

MFLD


Le 27/02/2017 à 20:53, Jody Bruchon a écrit :
> The recent flare-up of networking development has led to a lot of 
> additional small programs on the full disk images and that forced me 
> to eliminate other programs from being installed automatically to 
> avoid image build failures. I'd like to suggest some things that can 
> be done to reduce the amount of space these are taking up.
>
> Since all programs are statically linked to C library components, it 
> would be helpful to condense similar programs into a single binary 
> where possible, have the Makefile's install section create relative 
> symlinks, and change the program's behavior based on the name used to 
> invoke it. The code to do this obviously has its own overhead as well, 
> so it's only practical if there are enough binaries to justify the 
> trouble. You can find useful stuff for this in the "busyelks" project 
> I had been trying out and left in the code.
>
> It may also make sense to condense the new non-standard programs like 
> the "echo tests" into one binary and choose the specific functionality 
> with a command parameter instead.
>
> Another thing is the use of write() instead of [vf]printf(). If a 
> program can completely avoid the use of the printf() family of 
> functions and use write() instead, it'll make the program 
> significantly smaller on disk and in memory. If you must use printf() 
> even once then this isn't going to be helpful. If you can get away 
> with write() everywhere instead, the program will shrink and we'll be 
> able to fit more on disk.
>
> I'm sure more suggestions could be made and they would be most welcome.
>
> -Jody
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


  reply	other threads:[~2017-02-27 22:02 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-27 19:53 Condensing and re-coding programs to save space Jody Bruchon
2017-02-27 22:02 ` Marc-F. LUCCA-DANIAU [this message]
2017-02-27 22:11   ` Jody Bruchon
2017-02-28  9:31     ` Marc-François LUCCA-DANIAU
2017-02-28 11:54       ` Georg Potthast 2
2017-02-28 12:17         ` Jody Bruchon
2017-02-28 21:12 ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f3331a1c-4d89-024d-82b4-88ad60a3bf2b@gmail.com \
    --to=mfld.fr@gmail.com \
    --cc=Linux-8086@Vger.Kernel.Org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox