Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Kate Hsuan (via Email Bridge)
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 se

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Justin M. Forbes (via Email Bridge)
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 ma

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Hans de Goede (via Email Bridge)
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 reduc

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Justin M. Forbes (via Email Bridge)
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

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Hans de Goede (via Email Bridge)
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

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Hans de Goede (via Email Bridge)
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 ju

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Justin M. Forbes (via Email Bridge)
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 dr

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Don Zickus (via Email Bridge)
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 driver

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Hans de Goede (via Email Bridge)
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

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Justin M. Forbes (via Email Bridge)
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 n

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Don Zickus (via Email Bridge)
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 Fed

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Justin M. Forbes (via Email Bridge)
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 m

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Justin M. Forbes (via Email Bridge)
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, no

Re: [OS-BUILD PATCH 0/0] redhat: scripts: An automation script for disabling unused driver for x86

2023-12-07 Thread Prarit Bhargava (via Email Bridge)
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 cha