Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Kate Hsuan on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1685415116 Sounds good. I'll move all the stuff to `redhat/scripts/fedora`. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684872559 I don't disagree, though all new config items coming in for RHEL have to be reviewed by the subsystem owners anyway, and tend to default to off unless requested otherwise. There may be some cases of legacy hardware which isn't supported by newer RHEL versions, but RHEL would certainly have a different list. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Hans de Goede on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684863927 > recommend that we move all of this to `redhat/scripts/fedora` though as it is pretty fedora specific That sounds good to me. Although I would like to point out that with this reducing (theoretical) attack surface and with RHEL needing to maintain everything which is enabled for a long long time it might make sense to duplicate the changes into the RHEL config at some point too (by adjusting the script to do the disabling in redhat/configs/common/generic/x86/). -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684856741 I am okay with this concept. I might recommend that we move all of this to `redhat/scripts/fedora` though as it is pretty fedora specific at the moment. It will also allow me to set up ack rules so that RHEL maintainers do not need to review the changes to it. (This is a new directory, which might not have been present when this work was started) -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Hans de Goede on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684802550 > I am scratching my head how do we audit @hpa1 's list? One thing you can audit is if the removed i2c/spi drivers have an acpi_match_table. Without that they are basically not usable on x86 anyways (barring some exceptions of course). Other then that we will just need to trust the authors/maintainers of these allow lists (me in this case). > I still think with this approach, we may end up missing some eccentric hardware not in wide use, but it would be easy enough to turn those back on once a bug is filed. Right, so I plan to mostly limit this shrinking the kernel exercise to subsystems which I know well, which should significantly reduce the risk of accidentally disabling something which is used somewhere else after all. And if I make a mistake, as you say fixing this is easy once it is reported. And I do really hope that this makes it easy enough to do this to also get other people to maintain allow-list for other driver sub-dirs. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Hans de Goede on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684783523 So @hpa1 created this script at my request. Looking at the discussions here it seems there are 2 separate discussion points: 1. Why use a script 2. Why disable these drivers I've just answered 2. in the other thread below, so let me try to answer 1. here. The current way the redhat/configs/ dir / config-system works does not lend itself well to easily make big changes and it also does not really match with the mental model which I have of the kind of changes which I would like to make to reduce Fedora's kernel size. I asked Kate to make this script because I basically want to be able to specify an allow list for drivers in a certain subdir (e.g. drivers/iio/accel) . I have done a lot of work on x86 tablets so I know exactly which drivers are actually necessary and which ones are not. So to me the primary purpose of this script is to actually be able to express what I want: "only build these drivers" in a format which actually matches what I'm trying to express and then have this script translate this to the less then user-friendly redhat/configs/ "config-system" . The current x86_accel_allow file really is just the beginning and once this is in place I plan to add quite a few more, for starters at least for all the other subdirs under drivers/iio and also for drivers/regulators. Where there will be a single squashed commit for e.g. adding the new x86_iio_light allow file together with the results of running the script with that file for the first time. To me the script is just a way of being able to focus any time spend on this on what actually matters: "which drivers should stay enabled?" without having to spend a lot of time on the mechanism of then implementing the change once that question is answered. Now to answer the various rightfully asked questions: > How is the allow list maintained? Where is the information pulled from? I'm afraid the answer to that is maintained manually and the information comes from a domain expert. IOW the information comes from my brain (a mix of disabling spi/i2c drivers without an acpi_match_table + being aware of some exceptions). I do actually hope that having x86_disable_unused_drivers.py available may also help with experts of other parts of the kernel doing something similar for e.g. nic / switch drivers. > The script itself is not a bad idea, but it can not be run again after the next merge window unless someone, or ideally some automated process, can update the allow_list. Right the plan here is for separate subdir allow-list files to have a maintainer (me in this case) who say after rc2 is out runs the script on kernel-ark/os-build. Followed by manually looking at what the script disables and then either submits the results or updates the allow_list (or a mix of both). Since the upstream Kconfig does not really attempt to limit which drivers can be build on an arch to hw which are actually used in designs for that arch. And if that allow-list maintainer somehow misses a cycle then we just move forward as before with some extra driver enabled and hopefully the next cycle they do get around to it and also disable some drivers which were enabled unnecessarily in the previous cycle. Basically the idea behind the script is to make it easier to not just make this size reduction a one time thing, but to also actually maintain this over time. But this will still need *active *maintenance, with as fallback the old model of just enabling all the drivers. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684758822 > Right so you are kinda stuck and you default to on. Ok, I get your data source comment now (which is sorta the same as my who-decides-unnecessary comment). I would have thought drivers like these with no intention going on x86 would state that in the Kconfig, but perhaps they are stuck with the same reasoning: why limit it? With some they don't bother. With others they really don't know. A vendor makes a DAC chip, or a regulator, and a driver for it gets upstream. They are hoping to sell those chips to as many vendors as will buy them. AFAIK there is no central registry of "here's everything that is shipping". I still think with this approach, we may end up missing some eccentric hardware not in wide use, but it would be easy enough to turn those back on once a bug is filed. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684727952 Right so you are kinda stuck and you default to on. Ok, I get your data source comment now (which is sorta the same as my who-decides-unnecessary comment).I would have thought drivers like these with no intention going on x86 would state that in the Kconfig, but perhaps they are stuck with the same reasoning: why limit it? So yeah, I am scratching my head how do we audit @hpa1 's list? -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Hans de Goede on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684724074 So @hpa1 created this script at my request. Looking at the discussions above it seems there are 2 separate discussion points: 1. Why disable these drivers 2. Why use a script Let me try to explain 2. here in reply to "I believe Fedora purposely enables all drivers for an arch". There are a lot of drivers enabled in the Fedora x86 kernels for components which are simply never used in x86 designs and disabling these drivers gives a number of benefits: 1. Significantly reduce the kernel package size saving mirror diskspace and bandwidth 2. Significantly reduce the diskspace used by /lib/modules 3. Reduce kernel build times "I believe Fedora purposely enables all drivers for an arch" suggests that the kernel Kconfig itself does a good job of only allowing drivers to be build on archs where the drivers are actually relevant, which unfortunately most Kconfig entries do not even not try. E.g. there are a ton of drivers for i2c and spi attached chips which do not support ACPI enumeration, yet barring some special exceptions ACPI enumeration is the only way for an i2c or spi device to which such a driver can bind can be instantiated on x86. So compiling i2c or spi drivers which do not have an acpi_match_table is basically useless since there never will be e.g an i2c_client instantiated to which these drivers can bind. So basically the idea here is to limit the kernel configuration from "enables all drivers for an arch" to "enable all drivers which can actually be used on an arch". The drivers/iio/accel config changes here are really just an example of what I have in mind to do for many different drivers subdirs and in this example it reduces the amount of .ko files build under drivers/iio/accel from 33 to just 12. There are other cases like other iio subdirs, but also drivers/regulators where I plan to submit similar changes. Which together should result in significant savings. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684711819 While Fedora is very much interested in enabling any drivers for hardware that is or soon will be in the wild, there isn't much point in enabling a driver on an arch where it will never be used. The real problem with IIO and so many other chips, is drivers come before the hardware really. I know certain vendors regularly appear in laptops from major vendors, but I don't know which new chips the laptop vendors are planning to incorporate in future products. As a result, I tend to turn on most of them. Basically, if there is no actual way to use a driver on an arch, it is just extra surface area and should be disabled. If we had some sort of a legitimate data feed for several arches I would guess we could turn off hundreds of drivers. There is a similar problem with aarch64, in that several drivers end up enabled for SoCs that we will never run on because no vendor picks them up for a form factor of interest. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1684685920 This seems to conflict with Fedora's principle here a little. I believe Fedora purposely enables all drivers for an arch and thus is not interested in package size. The idea is that Fedora can cater to anyone who has the hardware (and the distro maintenance is low). Forcing the options off, while it makes sense makes me wonder what the line in Fedora is for enabling/disabling drivers? ELN/RHEL it is obvious: support. I feel like I am missing an angle here. Re-reading the changelog multiple times (I can follow the logic), I think I am stuck on who decides 'unnecessary'? Perhaps I am not convinced of the problem statement (I think if I was, the approach makes sense and I would have to think if that is a reasonable implementation). I don't know. Help? -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1683958591 I suppose I am curious as to why it is set up like this then. I do understand that new iio drivers can (and do) show up pretty much every merge window. Having an allow list would make sure that new drivers are disabled if they are not in that list. That means that we need a reliable data source to keep this list updated, or we will disable new x86 iio drivers by default, which does not make for a great user experience. Certainly the config changes here are acceptable. The script itself is not a bad idea, but it can not be run again after the next merge window unless someone, or ideally some automated process, can update the allow_list. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Justin M. Forbes on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1683946934 I still do not see how custom-overrides has anything to do with this. If the hardware doesn't exist on x86, it needs to be disabled on x86 permanently, not for a specific build, not for a specific system. The custom-overrides directory is supposed to remain empty for general use, it is for end users to make changes to the standard config. -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86
From: Prarit Bhargava on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1683927918 So I'll ask again: Why aren't you using the custom-overrides for this functionality, and tracking the contents of that file locally? It seems a better approach would be to apply changes there which can be per-build or per- system (depending on what you're doing)? -- ___ kernel mailing list -- kernel@lists.fedoraproject.org To unsubscribe send an email to kernel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
