Re: armel/marvell kernel size
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
Reply to: