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

Groups > linux.debian.kernel > #60019 > unrolled thread

Re: armel/marvell kernel size

Back to article view | Back to linux.debian.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#60645

Dear Rogério,

I'll reply to you later, in a separate email.


Dear kernel folks,

After all kinda tests recently, together with the patch from Leigh
Brown (CC-ed) that disabled VT, finally the armel/marvell can be
reduced under 2MB again, without introducing a new flavour.
So I already pushed the changes to master and sid branch in salsa.
qnap support will be back in next debian kernel release.

Cheers,
Roger

On Tue, Apr 3, 2018 at 2:37 PM, Rogério Brito <rbrito@ime.usp.br> wrote:
> Dear Roger, Ben and others.
>
> On Sun, Apr 1, 2018 at 10:25 AM, Roger Shimizu <rogershimizu@gmail.com> wrote:
>> On Wed, Jan 24, 2018 at 3:30 AM, Ben Hutchings <ben@decadent.org.uk> wrote:
>>> On Mon, 2018-01-22 at 22:38 +0900, Roger Shimizu wrote:
>>> There's an upstream change in cfg80211 that enables direct-loading of
>>> wireless rules, which requires public key crypto in the kernel.  There
>>> doesn't appear to be any option to disable that mode, even though we
>>> don't need it because crda still works.  Maybe you could disable
>>> wireless networking completely?
>>
>> I finally settled a solution, by introducing a new armel flavour:
>> mini, which doesn't support wireless.
>> There're still some users that need wireless, so I didn't remove
>> wireless from armel/marvell directly.
>
> I think that we should still strive to pretend that there's a hard 2MB
> limit and to shave some parts that can before we start creating a new
> flavor of the kernel... This would force us to think harder about
> disabling things in general... In general, I think that we can discuss
> a little bit more about what to include/exclude from such smaller
> kernels and which flavors to have.
>
> In other words, I agree with your end goal, but, perhaps, we can plan
> this a bit more...
>
>> So here I propose to have:
>> - marvell to support all generic feature and being able to tuned for
>> performance.
>> - mini without wireless and being minimum.
>>
>> Patches are all enclosed, and pushed to salsa rosh/armel_mini branch.
>> - 0001: Bring back qnap support by a new armel flavour: mini (Disable
>> WIRELESS, WLAN, etc)
>> - 0002: [armel/mini] Add flavour mini to installer
>> - 0003: [armel/mini] Further change a few features as module (I2C,
>> I2C_CHARDEV, I2C_MV64XXX,
>>   MTD, MTD_CMDLINE_PARTS, RTC_DRV_MV, and SPI_ORION)
>
> I would make your commits more granular, with one semantic change per
> commit, to revert and or/bisect in an easier fashion...
>
>> I tested on stretch by cross compiling, here's generated kernel size.
>> - original 4.16~rc6-1~exp2: 2142704
>> - After patch 0001: 2017088
>> - After patch 0002: 2017088
>> - After patch 0003: 1985896
>>
>> Here's my testing result regarding those features that changed to module:
>> (tested under stretch)
>
> I'm doing my tests under testing (buster). See more below.
>
>>> Some options that could possibly be changed from y to m:
>>>
>>> - I2C, I2C_CHARDEV, I2C_MV64XXX.  initramfs-tools should include I2C
>>> drivers to the initramfs if needed, but I'm not certain.
>>
>> No, i2c nor i2c_mv64xxx will be loaded. But my armel box seems fine
>> without them.
>> Of course, manually "modprobe i2c_mv64xxx" will load the module well.
>
> While I have compiled a kernel with those options all enabled as
> modules, I have not yet had time to boot it (in fact, I created a lot
> of kernels that I want to test all in one sitting), but I agree with
> the principle of your testing, Roger and, in the worst case, we can
> instruct the users to add those to /etc/modules if they absolutely
> need them.
>
> I would not qualify this as a change for only a new kernel flavor,
> that is, I would make this change in general...
>
>>> - MTD, MTD_CMDLINE_PARTS, etc.  But I'm pretty sure this will break
>>> some systems unless initramfs-tools is updated to include and load the
>>> cmdlinepart module.
>>>
>>> - RTC_DRV_MV (and disable RTC_HCTOSYS).  There's a udev rule that
>>> should load the system clock from the first RTC if its driver is a
>>> module.
>>>
>>> - SPI_ORION.  initramfs-tools should include this in the initramfs if
>>> needed, but I'm not certain.
>>
>> Yes, above 3 modules are loaded without glitch.
>
> All those are generic material that I would also make generic instead
> of only particular to a given flavor.
>
>>> Some options that could possibly be disabled:
>>>
>>> - AUDIT.  This is quite a niche feature.
>>
>> I tried, but couldn't. Maybe next time.
>
> You probably missed this, but I said in a previous message that AUDIT
> is automatically selected by AppArmor. In other words, you can have
> only the following options:
>
> * with AppArmor (and AUDIT)
> * without AppArmor (but with AUDIT)
> * without AppArmor and without AUDIT
>
> From my perception, Ben was mildly opposed to having AppArmor disabled
> by default and wanted to have the kernel as close as possible to other
> arches...
>
> For that reason, I would still keep AppArmor in the big, reference
> armel kernel, but opt to create a flavor without AppArmor (and without
> AUDIT) for the people that may want to use a small kernel or for those
> (like me) that never use AppArmor (or that have not yet seen the light
> with the benefits of a MAC module).
>
> Besides your proposed changes, I have some other things in mind that I
> have in patches here and that I will send after I get access to the
> notebook where I compiled things:
>
> 1 - I would change from the CFQ to the DEADLINE governors *in the
> general kernel*, as it makes the kernel slightly smaller, but, in my
> experience, working as well as a CFQ in practice.
> 2 - Another excellent option is CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
> suggested by Leigh Brown (taken from
> https://lists.debian.org/debian-arm/2018/03/msg00035.html). The amount
> of reduction in size with my system was surprising (much smaller than
> what I expected by changing the governors or when changing some
> options from y to m).
>
> Since I mentioned my environment, please, keep in mind that:
>
> * The compiler that I am using for everything here is the one from
> testing (buster) and it is GCC 7 at the moment (have not tried using
> GCC 8 to see the differences yet)
> * I am optimizing things for size (which, in some cases, may be
> beneficial for machines with small L1/L2 caches too)
>
> I would change the default from optimizing for size (-Os) to
> optimizing for speed (-O2) only after all the low-hanging fruit with
> kernel options were decided and, then, I would think hard if it makes
> sense to have -O2 with a small kernel or with the full blown kernel.
>
> Another option suggested by Leigh in that message was that
>
> +# CONFIG_CRC32_SLICEBY8 is not set
> +CONFIG_CRC32_SLICEBY4=y
>
> can make the kernel smaller and, if I remember the descriptions of the
> options, it made sense that those would reduce the size of the kernel
> both compressed and uncompressed... This would be something that I
> would suggest for a general kernel also...
>
> I am not sure about disabling the VT option as Leight suggested... I
> don't think that I have ever used one of those...
>
> I think that we can compile out YAMA from the general kernel, since, I
> would believe that it is less frequently used (we can upload a kernel
> with this disabled to experimental or to a personal space and ask
> people to experiment it) and it is disabled by default in Debian's
> kernel...
>
> For a -mini kernel, some of the first things that come to my mind
> would be to disable:
>
> * some hardware framebuffers like the S3 and similar ones, even if
> build as modules.
> * your suggestion of disabling wifi drivers and the wifi subsystem
> * disabling some less commonly used local or distributed filesystems
> (some of which are large or demand many other options to be enabled)
> or that have better functionality in userspace (like the NTFS read
> support in the kernel being disabled and recommend ntfs3g to the
> users), but keeping popular ones and services like ext2/3/4, XFS, NFS,
> Mounting CIFS is probably a good idea, but having OCFS or other
> systems, I don't know.
> * disabling some partition types for the smaller kernels, after
> benchmarking them...
> * disabling joystick/video/audio capture etc drivers.
> * disabling yama/apparmor/audit.
> * disabling unused kernel algorithms or those that aren't pulled in by
> any modules (I remember at least one that said: don't enable this one
> unless you have an out-of-tree module that needs it).
>
> Oh, I would *not* disable zswap from the smaller kernel, since I would
> plan on going not only with zbud but also with z3fold and test the
> stability and performance of the kernel with it, as machines that are
> memory-starved can benefit from a higher density of compression...
>
> When introducing a new flavor, I guess that we could make the current
> flavor, instead of none, being -standard, a new one called -mini
> (similar in spirit to yours) and, potentially, another called -micro
> to users of DNS323 (if the -mini flavor does not fit in the 1.5MB
> after all these changes)...
>
> Furthermore, with the LTO work on the kernel, I am hopeful that
> if/when it gets merged, we can make everything even smaller and be
> much happier... :-) OK, I'm excited to have very small kernels despite
> the kernel in general growing from version to version with more and
> more features being integrated...
>
> Please, let me know your opinions.
>
> I will now go to bed, but I will send my patches as soon as I wake up
> and deal with morning stuff. In the end, I intend to enable support
> for as many things are available in the mainline (even the DNS323, for
> which I don't have the hardware, but since we are with our hands
> dirty, let us extend the value of those machines for the users of such
> hardware...)
>
> Thanks,
>
> Rogério Brito.
>
> P.S.: Only now I saw that one of your patches already implement the
> option that Leigh suggested... But I think that we can use more
> modular options both in the "main" kernel and in the smaller flavors.
>
> P.P.S.: Sorry if this message is badly composed, if there are
> unfinished sentences or if something doesn't make sense, but I just
> wanted to make sure that the thoughts that I have here in my head get
> discussed with others and not only confined to myself.
>
> --
> Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
> http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
> DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

[toc] | [prev] | [next] | [standalone]

#60647

On Sat, Apr 7, 2018 at 11:16 PM, Roger Shimizu <rogershimizu@gmail.com> wrote:
> Dear kernel folks,
>
> After all kinda tests recently, together with the patch from Leigh
> Brown (CC-ed) that disabled VT, finally the armel/marvell can be
> reduced under 2MB again, without introducing a new flavour.

Sorry, I forgot to mention the post that Leigh Brown provided the patch:
- https://lists.debian.org/debian-kernel/2018/03/msg00223.html

And the patch, reducing armel image size under 2MB, and pushed to
master branch is:
- https://salsa.debian.org/kernel-team/linux/commit/a4fdfa09

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#60680

On Sun, Apr 8, 2018 at 5:47 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Sat, 2018-04-07 at 23:38 +0900, Roger Shimizu wrote:
>> On Sat, Apr 7, 2018 at 11:16 PM, Roger Shimizu <rogershimizu@gmail.com> wrote:
>> > Dear kernel folks,
>> >
>> > After all kinda tests recently, together with the patch from Leigh
>> > Brown (CC-ed) that disabled VT, finally the armel/marvell can be
>> > reduced under 2MB again, without introducing a new flavour.
>>
>> Sorry, I forgot to mention the post that Leigh Brown provided the patch:
>> - https://lists.debian.org/debian-kernel/2018/03/msg00223.html
>>
>> And the patch, reducing armel image size under 2MB, and pushed to
>> master branch is:
>> - https://salsa.debian.org/kernel-team/linux/commit/a4fdfa09
>
> Well done!

Dear Ben,

Unfortunately, armel FTBFS on buildd due to udeb [0][1].

[0] https://buildd.debian.org/status/package.php?p=linux&suite=experimental
[1] https://buildd.debian.org/status/fetch.php?pkg=linux&arch=armel&ver=4.16-1~exp1&stamp=1523350611

Neither the cross build wiki entry [2], nor the kernel handbook [3]
mentions how to build udeb.
So could you kindly tell me how to confirm the udeb build?

[2] https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage
[3] https://kernel-handbook.debian.net

BTW. I think the udeb breaks because I removed RD_BZIP2 and RD_LZMA.
So if you know how to fix the config under debian/installer, please
kindly help to do.
I don't have enough knowledge to touch stuff under that directory. Thank you!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#60686

Dear Ian, Ben,

On Sun, Apr 15, 2018 at 9:50 PM, Ben Hutchings <ben@decadent.org.uk> wrote:
> On Sun, 2018-04-15 at 08:16 +0100, Ian Campbell wrote:
>> On Sun, 2018-04-15 at 00:08 +0100, Ben Hutchings wrote:
>> > > For the lzo_decompress ones I think you need to add it to
>> > > installer/modules/lzo-modules and perhaps add one or two more
>> > > dependencies based on what the errors are at that point.
>> >
>> > Let's not introduce more packages.  I would be tempted to put it in
>> > kernel-image, which all other udeb packages should depend on.
>>
>> I thought lzo-modules already existed, but perhaps my tree was out of
>> date. If it doesn't then you are right that kernel-image would be a
>> find choice.
>
> You're right, I just didn't remember it existing.

Thanks for your hints!
I also find the thread [0] that had the similar problem before.
So I learned how to fix the problem, and now the fix is in master [1]
and sid branch on salsa.

[0] https://lists.debian.org/debian-kernel/2014/02/msg00341.html
[1] https://salsa.debian.org/kernel-team/linux/commit/175171d4

I also find the target binary-arch_armel_real of makefile fails in my
cross compiling environment, which is the reason why I couldn't build
udeb.
There's a workaround for this:
$ sed -i 's/binary-arch_armel:: binary-arch_armel_extra
binary-arch_armel_none binary-arch_armel_real/binary-arch_armel::
binary-arch_armel_extra binary-arch_armel_none/' debian/rules.gen

After that, the udeb command can be built by ($ARCH is armel for my case):
$ fakeroot make -f debian/rules.gen binary-arch_${ARCH}

Maybe it's kinda dirty hack, but works for me. I also realized that I
never used the binary-arch_armel_real target before.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

[toc] | [prev] | [next] | [standalone]

#60613

On Mar 28, 2018, at 2:22 AM, Rick Thomas <rbthomas@pobox.com> wrote:

>> What filesystems do you use? Do you use any (para)virtualization? What
>> about addon hardware that you have? Any USB dongles? Anything that you
>> can think of? Sound?
>> 
>> Do you use NFS? (I do) What kind of compressed ramdisk do you use? The
>> loaded modules that you have with lsmod would be nice to know.
> 

Filesystems:  ext2 and ext4

Vitrualization: Nope.  These are way too small for anything fancy like that.

Addon hardware:
	USB2 ports useful for disk and/or flash drives and other stuff (I don’t do the “other stuff” myself but I suppose there are folks who might).
	They have 1000BaseT ports.  Two ports on the OpenRD Client, one on the SheevaPlug.
	They each have a mini-USB serial port that they use for serial console.
	The Client has a headphone jack.  I’ve used it in the past for listening to streaming radio.  The SheevaPlug has no audio i/o.
	Both machines have SD-card slots that can be used in booting or as aux data storage.
	Both get their uboot from mtd, not mmc, so updating uboot requires re-flashing.
	The Client has 512MB RAM.  The SheevaPlug has the same.

	CPU info for SheevaPlug —
> root@sheeva:~# cat /proc/cpuinfo
> processor	: 0
> model name	: Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS	: 1185.79
> Features	: swp half thumb fastmult edsp 
> CPU implementer	: 0x56
> CPU architecture: 5TE
> CPU variant	: 0x2
> CPU part	: 0x131
> CPU revision	: 1
> 
> Hardware	: Marvell Kirkwood (Flattened Device Tree)
> Revision	: 0000
> Serial		: 0000000000000000

	CPU info for OpenRD Client —
> rbthomas@client:~$ cat /proc/cpuinfo 

> processor	: 0
> model name	: Feroceon 88FR131 rev 1 (v5l)
> BogoMIPS	: 1191.93
> Features	: swp half thumb fastmult edsp 
> CPU implementer	: 0x56
> CPU architecture: 5TE
> CPU variant	: 0x2
> CPU part	: 0x131
> CPU revision	: 1
> 
> Hardware	: Marvell Kirkwood (Flattened Device Tree)
> Revision	: 0000
> Serial		: 0000000000000000

	Uboot details on SheevaPlug —
> U-Boot 2016.01-rc3+dfsg1-3 (Jan 02 2016 - 23:19:11 +0000)
> Marvell-Sheevaplug
> 
> SoC:   Kirkwood 88F6281_A0
> DRAM:  512 MiB (ECC not enabled)
> WARNING: Caches not enabled
> NAND:  512 MiB
> MMC:   MVEBU_MMC: 0
> In:    serial
> Out:   serial
> Err:   serial
> Net:   egiga0

	and on OpenRD Client —
> U-Boot 2016.11+dfsg1-4~20170308~1 (Mar 09 2017 - 01:27:49 +0000)
> OpenRD-Client
> 
> SoC:   Kirkwood 88F6281_A0
> DRAM:  512 MiB
> WARNING: Caches not enabled
> NAND:  512 MiB
> MMC:   MVEBU_MMC: 0
> In:    serial
> Out:   serial
> Err:   serial
> Net:   egiga0, egiga1
> 


I use the SheevaPlug as a backup DHCP/DNS server for my home network.  The Client is reserved for experimenting.

I don’t currently use NFS on either, but I have in the past.

I’m not sure what you mean by “What kind of compressed ramdisk do you use?”.  As a stab in the dark —

> rbthomas@client:~$ file /boot/initrd.img-4.9.0-6-marvell
> /boot/initrd.img-4.9.0-6-marvell: gzip compressed data, last modified: Sun Mar  4 14:29:43 2018, from Unix

and

> root@sheeva:~# file /boot/initrd.img-4.9.0-6-marvell
> /boot/initrd.img-4.9.0-6-marvell: gzip compressed data, last modified: Sat Mar 10 10:12:39 2018, from Unix

In other words, nothing fancy!

Does that help?
Rick

[toc] | [prev] | [next] | [standalone]

#60587

>> I can answer this part: yes, you can definitely put an Intel wifi card
>> in the mini-pcie slot of an ARM box.
> This means that, in principle, we should enable many modules more to get
> as full support as desired in Debian on each and every arch...

My point wasn't just that it's technically possible, but since those
Intel wifi mini-pcie cards are ubiquitous (found in most old discarded
laptops you may have lying around), it's fairly likely that someone will
want to use one of those.


        Stefan

[toc] | [prev] | [next] | [standalone]

#60581

[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.

[toc] | [prev] | [next] | [standalone]

#60582 — Re: armel not to be released anymore? (was: armel/marvell kernel size)

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

On Tue, 2018-03-27 at 21:21 +0200, W. Martin Borgert wrote:
> Quoting Ben Hutchings <ben@decadent.org.uk>:
> > Still, as armel will not be a release architecture any more, I
> > suppose
> > it can diverge further from the normal configuration.
> 
> I didn't know, that this already has been decided.
> Could you point to the emails about this? Thanks!

I don't know about emails, but the status page says it is not a
candidate: https://release.debian.org/buster/arch_qualify.html

Ben.

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

[toc] | [prev] | [next] | [standalone]

#60583 — armel not to be released anymore? (was: armel/marvell kernel size)

Quoting Ben Hutchings <ben@decadent.org.uk>:
> Still, as armel will not be a release architecture any more, I suppose
> it can diverge further from the normal configuration.

I didn't know, that this already has been decided.
Could you point to the emails about this? Thanks!

[toc] | [prev] | [next] | [standalone]

#60590 — Re: armel not to be released anymore? (was: armel/marvell kernel size)

On Wed, Mar 28, 2018 at 3:21 AM, W. Martin Borgert wrote:
> Quoting Ben Hutchings:
>>
>> Still, as armel will not be a release architecture any more, I suppose
>> it can diverge further from the normal configuration.
>
> I didn't know, that this already has been decided.
> Could you point to the emails about this? Thanks!

https://lists.debian.org/msgid-search/20180207184636.ukfil2kybr7jcweu@betterave.cristau.org
https://lists.debian.org/msgid-search/20170914024001.kitowt4moob5hyso@tack.einval.com

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

[toc] | [prev] | [next] | [standalone]

#60586

Hi, Ben and others following the discussion.

On 2018-03-27 16:01, Ben Hutchings wrote:
> 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:
>>
>> (...)
>>
>> 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.

Running make menuconfig, I can disable it without any visible loss (not
yet run it, but I don't have such hardware on my Kurobox Pro).

If the kernel were only for me, then I would simply kill it, and be done
with it, but, as I wrote to Stefan, the logical consequence would be to
enable everything that could plausibly be used... OTOH, if people
haven't noticed by this time that we need some drivers, perhaps we
shouldn't be enabling such a thing...

(Yes, I know that enabling a given driver can, say, enable some data
structure implementation from the core of the kernel and/or some crypto
algorithm, which would make the kernel potentially bigger).

> 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.

Right. I suspected this much.

> However there are some cases
> where a modular driver may require (and select) a feature that is
> always built-in.

Oh, yes this I knew.

>> 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

This I didn't know. :-)

>> 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.

OK, I will reenable apparmor and see what size I get before sending patches.

> Still, as armel will not be a release architecture any more, I suppose
> it can diverge further from the normal configuration.

I saw your other email. I would like to revert this and I don't know if
(finally, after more than a decade contributing to Debian as a Debian
Maintainer) it is time to step up and become a Debian Developer and
commit to maintain some parts of the kernel...

Yes, that means that if this excursion of mine is fruitful, I will
volunteer... :-) If not, then I just get the learning experience. :-)

Actually, if I succeed, I would be interested in also working to get
powerpc revived, since I have an iBook G3, an iBook G4 and two ppc-based
kuroboxes (but one of them has only 64MB of RAM and I still have to
learn this device tree syntax)...

>> 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.

I didn't know that. I guess that I cloned the repository after he made
that change... Anyway, I will check it, but the kurobox Pro is (in my
understanding) very close to a linkstation...

>> 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.

For the moment, I will try to work with the 2MB limit in mind, since I
want the QNAP boxes also working...

BTW, I think that my idea of supplying an alternate flavor was in the
mind of other people simultaneously (that is it is the zeitgeist), since
I see many other people talking about this on the other thread...

Perhaps the assumption that the current kernel needs all the bells and
whistles is being challenged...

Anyway, back to the apparmor test now...


Thanks,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.kernel

csiph-web