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 <rbr...@ime.usp.br> wrote: > Dear Roger, Ben and others. > > On Sun, Apr 1, 2018 at 10:25 AM, Roger Shimizu <rogershim...@gmail.com> wrote: >> On Wed, Jan 24, 2018 at 3:30 AM, Ben Hutchings <b...@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
