Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adding a BUILD_EXCLUSIVE_KERNEL... blacklist? #369

Open
anbe42 opened this issue Nov 30, 2023 · 3 comments
Open

adding a BUILD_EXCLUSIVE_KERNEL... blacklist? #369

anbe42 opened this issue Nov 30, 2023 · 3 comments

Comments

@anbe42
Copy link
Contributor

anbe42 commented Nov 30, 2023

Right now we have BUILD_EXCLUSIVE_KERNEL as a regex that whitelists kernel versions. With the recently added BUILD_EXCLUSIVE_KERNEL_MIN/MAX that whitelist regex probably gets less used. But sometimes I'd rather like to blacklist a single (or a few) incompatible kernel versions ... so a regex would still be nice, but negating it into a whitelist makes it unreadable, e.g. ^([1-4]\.|5\.[0-46-9]\.|5\.[1-9][0-9]|[6-9]\.|[1-9][0-9]).
I might add such a directive, but I cannot come up with a good name for it.
And we can't simply prefix the BUILD_EXCLUSIVE_KERNEL value with '!' to negate its meaning, as the would break usage on older dkms versions.

@evelikov
Copy link
Collaborator

evelikov commented Dec 6, 2023

Negating BUILD_EXCLUSIVE that means we want a BUILD_REQUIRES right?

Overall I like the idea, but I'm a little concerned about:

  • conflicting configuration - doable but needs documentation and tests, which can raise the complexity
  • forward and backward compatibility - say I create a new dkms module that uses the new token and some users try it against older dkms

Latter is a bit moot point, since we don't do much of that atm. The former seems far more relevant IMHO.

@anbe42
Copy link
Contributor Author

anbe42 commented Dec 6, 2023

I would see it more as BUILD_EXCLUDE, but that's visually very similar ..

I don't see a potential for conflicting configuration. All BUILD_EXCLUSIVE_* settings define some contraints, and if a kernel does not match any one of them it is thrown out.

New directives will be ignored by older dkms, we just shouldn't change the meaning of the previously existing ones ...
The modules will simply fail to build with the older dkms since it was impossible to express the constraint to exclude that kernel at that time.

@evelikov
Copy link
Collaborator

evelikov commented Dec 7, 2023

I may or may not have misread "exclusive" as "exclude" in the first place 😛

Speaking of conflicting configuration, let's consider BUILD_EXCLUSIVE=5.1 and BUILD_EXCLUDE=5.*. This should result in 0 modules handled, correct? It is somewhat of a nonsensical config, so I'm wondering if that should be success, skip or failure? Do we want to inform the user about the potential typo/miss-config?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants