Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #60581

Re: armel/marvell kernel size

Cross-posted to 2 groups.

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Tue, 2018-03-27 at 02:30 -0300, Rogério Brito wrote:
[...]
> > > I will see if all the modules make sense for an embedded system like this
> > > and I will send a list of options for opinions by others...
> > 
> > [...]
> > 
> > As I see it, the point of installing Debian on little NAS boxes is to
> > break out of the restrictions of an embedded system.  We try to
> > provide, so far as possible, the same features across all
> > architectures.
> 
> It sure makes sense to provide a lot more than some kernels, but I am
> curious about some features that end up as modules like some
> framebuffer like the following:
> 
> (...)
> # CONFIG_FB_MATROX is not set
> # CONFIG_FB_RADEON is not set
> # CONFIG_FB_ATY128 is not set
> # CONFIG_FB_ATY is not set
> CONFIG_FB_S3=m
> CONFIG_FB_S3_DDC=y
> # CONFIG_FB_SAVAGE is not set
> # CONFIG_FB_SIS is not set
> # CONFIG_FB_NEOMAGIC is not set
> # CONFIG_FB_KYRO is not set
> CONFIG_FB_3DFX=m
> # CONFIG_FB_3DFX_ACCEL is not set
> CONFIG_FB_3DFX_I2C=y
> # CONFIG_FB_VOODOO1 is not set
> (...)
> 
> Is there any reason why, say, a driver for an S3 card is enabled while
> not for a Matrox?

I don't know; that doesn't make a lot of sense.

The Kirkwood SoCs have external PCIe links and some of the supported
devices (like OpenRD) provide PCIe expansion slots, so most PCIe device
drivers should be enabled.

> Are there real users for those? I know that, as
> modules, they don't make the kernel bigger, but they sit there on
> disk, doing nothing (right?).

They probably don't make a difference.  However there are some cases
where a modular driver may require (and select) a feature that is
always built-in.

> Similarly for wifi cards like those Intel ones like iwlwifi (which is
> the one that I have in this Core 2 Duo here)...

Prepare to be amazed: https://www.amazon.com/dp/B00OM0L9ZO

> OK, now to the real meat of my message.  Regarding shrinking the
> kernel image, I was able to tweak things slightly (drop from 101% down
> to 98%) by disabling APPARMOR, YAMA, AUDIT, making the kernel use the
> deadline IO scheduler instead of the CFQ and making as modules the
> ones that you suggested in the original message... Is that acceptable?

I would really rather we avoided disabling AppArmor, since it is not
only built-in but also enabled by default on all other architectures. 
Still, as armel will not be a release architecture any more, I suppose
it can diverge further from the normal configuration.

> If so, then I will test them on my Kurobox Pro and report what works
> and what breaks. I just wanted to get things smaller by tackling some
> lower hanging fruit...
> 
> Another point: from what I saw in the Debian scripts, not all
> armel/marvell systems are limited to 2MB (in particular, the Kurobox
> Pro with which I am most concerned still has 630KB of room)...

Roger has increased the size limit to 2729712 on the sid branch, which
is the limit on the Buffalo Linkstation devices.  Check whether that
matches the Kurobox Pro too.

> In the
> very worst case (of course, this is not what we want), if the kernel
> actually gets much bigger in time for the buster release, we could
> selectively drop some systems (like what was done with the DNS323)
> instead of dropping an entire arch... I even think that a new,
> smaller, alternative flavor of the kernel is possible to provide to
> support those systems that are limited to 2MB of kernel image... (I
> can commit to support that, if my initial ideas work and people accept
> them).

Either of those seem like reasonable options.

Ben.

> Of course, if we could make some real magic and make our kernels much,
> much smaller to support back the DNS323, that would be amazing... :-)
> 
> I guess that I will look into those LTO patches in the future...
> 
> OK, I am sending this to see if those ideas make sense, to offer my
> help and, of course, to get some feedback.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-01-18 05:30 +0100
  Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-01-22 15:00 +0100
    Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-01-23 19:40 +0100
      Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-01-26 19:00 +0100
      Re: armel/marvell kernel size Salvatore Bonaccorso <carnil@debian.org> - 2018-02-17 13:50 +0100
        Re: armel/marvell kernel size Bastian Blank <waldi@debian.org> - 2018-02-17 14:20 +0100
          Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-03-22 13:00 +0100
        Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-03-22 13:00 +0100
          Re: armel/marvell kernel size Rogério Brito <rbrito@gmail.com> - 2018-03-22 19:20 +0100
        Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-03-23 00:10 +0100
        Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-03-24 03:00 +0100
          Re: armel/marvell kernel size Rogério Brito <rbrito@gmail.com> - 2018-03-27 07:50 +0200
            Re: armel/marvell kernel size Stefan Monnier <monnier@iro.umontreal.ca> - 2018-03-27 14:40 +0200
              Re: armel/marvell kernel size Rogério Brito <rbrito@ime.usp.br> - 2018-03-27 22:30 +0200
                Re: armel/marvell kernel size Rick Thomas <rbthomas@pobox.com> - 2018-03-27 22:50 +0200
                Re: armel/marvell kernel size Rogério Brito <rbrito@ime.usp.br> - 2018-03-27 23:30 +0200
                Re: armel/marvell kernel size Rick Thomas <rbthomas@pobox.com> - 2018-03-28 11:30 +0200
                Re: armel/marvell kernel size Federico Pietro Briata <federico@briata.org> - 2018-03-28 14:30 +0200
                Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-04-01 15:30 +0200
                Re: armel/marvell kernel size Rogério Brito <rbrito@ime.usp.br> - 2018-04-03 08:00 +0200
                Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-04-07 16:20 +0200
                Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-04-07 17:00 +0200
                Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-04-13 02:10 +0200
                Re: armel/marvell kernel size Roger Shimizu <rogershimizu@gmail.com> - 2018-04-15 18:30 +0200
                Re: armel/marvell kernel size Rick Thomas <rbthomas@pobox.com> - 2018-04-02 01:50 +0200
                Re: armel/marvell kernel size Stefan Monnier <monnier@iro.umontreal.ca> - 2018-03-27 23:30 +0200
            Re: armel/marvell kernel size Ben Hutchings <ben@decadent.org.uk> - 2018-03-27 21:10 +0200
              Re: armel not to be released anymore? (was: armel/marvell kernel  size) Ben Hutchings <ben@decadent.org.uk> - 2018-03-27 21:30 +0200
              armel not to be released anymore? (was: armel/marvell kernel size) "W. Martin Borgert" <debacle@debian.org> - 2018-03-27 21:40 +0200
                Re: armel not to be released anymore? (was: armel/marvell kernel size) Paul Wise <pabs@debian.org> - 2018-03-28 06:40 +0200
              Re: armel/marvell kernel size Rogério Brito <rbrito@ime.usp.br> - 2018-03-27 22:50 +0200

csiph-web