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
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
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
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
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
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
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
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
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
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
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
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
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,
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
From: Kate Hsuan on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1683371062
@jmflinuxtx Thank you for answering this.
I've updated the motivation in the description section. The idea is to disable
the unnecessary driver if we confirm the drivers are not used for
From: Kate Hsuan on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1683344539
Hi,
I've updated the motivation of this work in the description section.
The main idea of it is to reduce the kernel module package size. We can
disable the unnecessary driver and
From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1682187133
The problem being solved would be unnecessarily enabled drivers. Turning them
off lowers attack surface among other things. I would absolutely love a solid
data source which tells
From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1682131422
Then, like @jstancek , I don't understand the problem being solved here.
--
___
kernel mailing list -- kernel@lists.fedoraproject.org
To
From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1682054528
I don't see why we would be using custom-overrides for this at all. If it is
hardware that does not exist on x86, we should be disabling the config there.
We have an issue that
From: Prarit Bhargava on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1682032702
Not to pile on but if you want to use the 'standard' config we've laid out and
then disable or enable configs, then why aren't you using the custom-overrides
functionality as
From: Jan Stancek on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1682015217
@hpa1 Can you please add to description what problem/bug is this MR solving?
Seeing this MR with no prior info, I can understand the 2nd commit (disable
bunch of configs), but I have
From: Justin M. Forbes on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832#note_1681957728
While I certainly like the concept, how is the allow list maintained? Where
is the information pulled from?
--
___
kernel mailing list
From: Kate Hsuan on gitlab.com
Merge Request: https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2832
NOTE: Truncated patchset due to missing public @redhat.com email
address on your GitLab profile at https://gitlab.com/-/profile.
Once that is fixed, close and reopen the merge
23 matches
Mail list logo
