Announcement

Collapse
No announcement yet.

Linux 5.18 To Try Again For x86/x86_64 "WERROR" Default

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • milkylainen
    replied
    Originally posted by WizardGed View Post

    do you know how to calculate/list the symbols without a config creating a script that counts these and lists them is step 1 really then separating them into the relevant kernel maintainer groups to raise a specific bug is the the first step. possibly a ci/cd test after to keep the count down. you can't attack something that large and widespread in one single commit.
    I didn't say anything about attacking the problem by manually poking all arch/board maintainers.
    What I did say, indirectly, was to re-enable the warnings about non-existent symbols.
    Much like various compiler warnings.

    The kconfig warnings in question were removed in 2008 and the list of broken symbols has been ever increasing since.


    I love the logic there. "We have warnings about broken configuration. Annoying. Lets hide them."

    Leave a comment:


  • WizardGed
    replied
    Originally posted by milkylainen View Post

    Symbols that exist in various defconfigs that don't match up anywhere in the config system (indirectly code base), yes.
    So it's not symbols that show up in a config utility. They need a description somewhere in the config system. Doesn't mean that they can't be wrong too.

    It's more often symbols gone dead or not migrated properly.
    Like CONFIG_SOMETHING_DRIVER used to work, but someone forgot to rename it to CONFIG_SOMETHING_NEW_DRIVER (namechange),
    so it doesn't match anything in the descriptions anymore.
    Some of them are just stupid mistakes. Others are like "wtf. I'm not sure some functionality has gone missing here..."

    The three categories are a bit disjunct. They live their own life and rely mostly on manual handling to align them.
    1. Symbols in the defconfigs (yes, partly manual, otherwise there wouldn't be so many dead symbols).
    2. Symbols in code.
    3. Symbols in the definition system (kconfig/lxdialog).

    This is esp. painful for system maintainers.
    But kernel developers usually don't care enough to inspect configuration migration mishaps between generations of the kernel.
    do you know how to calculate/list the symbols without a config creating a script that counts these and lists them is step 1 really then separating them into the relevant kernel maintainer groups to raise a specific bug is the the first step. possibly a ci/cd test after to keep the count down. you can't attack something that large and widespread in one single commit.

    Leave a comment:


  • yurikoles
    replied
    milkylainen this knowledge looks like a good start into Linux kernel development. Having at least one commit in mainline kernel is my dream since high school.

    Leave a comment:


  • milkylainen
    replied
    Originally posted by WorBlux View Post

    WTF?

    Are we talking symbols that show up on the config utility but no longer exist in the codebase, or the other way around?

    Either way... ouch.
    Symbols that exist in various defconfigs that don't match up anywhere in the config system (indirectly code base), yes.
    So it's not symbols that show up in a config utility. They need a description somewhere in the config system. Doesn't mean that they can't be wrong too.

    It's more often symbols gone dead or not migrated properly.
    Like CONFIG_SOMETHING_DRIVER used to work, but someone forgot to rename it to CONFIG_SOMETHING_NEW_DRIVER (namechange),
    so it doesn't match anything in the descriptions anymore.
    Some of them are just stupid mistakes. Others are like "wtf. I'm not sure some functionality has gone missing here..."

    The three categories are a bit disjunct. They live their own life and rely mostly on manual handling to align them.
    1. Symbols in the defconfigs (yes, partly manual, otherwise there wouldn't be so many dead symbols).
    2. Symbols in code.
    3. Symbols in the definition system (kconfig/lxdialog).

    This is esp. painful for system maintainers.
    But kernel developers usually don't care enough to inspect configuration migration mishaps between generations of the kernel.

    Leave a comment:


  • WorBlux
    replied
    Originally posted by milkylainen View Post
    Linus won't accept anything but -Werror but is fine with the configs in disarray?
    Something like 1k+ non-existent symbols in various defconfigs last time I checked.
    WTF?

    Are we talking symbols that show up on the config utility but no longer exist in the codebase, or the other way around?

    Either way... ouch.

    Leave a comment:


  • mether
    replied
    Originally posted by EvilHowl View Post

    Yeah. Why bother fixing warnings when we can rewrite the whole kernel in Rust?
    Rust usage in kernel still doesn't involve cargo. So the OP's comment doesn't make sense even then.

    Leave a comment:


  • JMB9
    replied
    Originally posted by JEBjames View Post
    Michael

    Hydrogen (h) is the most prevalent element in the universe?

    But despite the article author's great wit, it can be mysteriously missing.

    Typo: "wit" should be "with".
    Well, h is the Planck constant and the chemical symbol for hydrogen is H.
    And seriously - "witH" looks even more strange than "wit", don't you think?
    But maybe it is just a generation conflict - not using real digital devices without
    touchpad but 'smart' devices may result in such mistakes without noticing ...
    The normal world is case sensitive ... at least I hope so.
    Additionally, this discussion is 2 days late ....

    Leave a comment:


  • EvilHowl
    replied
    Originally posted by uid313 View Post
    What about switching from C11 to C17?

    Or from gcc to cargo?
    Yeah. Why bother fixing warnings when we can rewrite the whole kernel in Rust?

    Leave a comment:


  • NateHubbard
    replied
    Originally posted by JEBjames View Post
    Michael

    Hydrogen (h) is the most prevalent element in the universe?

    But despite the article author's great wit, it can be mysteriously missing.

    Typo: "wit" should be "with".
    I was a little more hung up on the "treated serious" line.

    Leave a comment:


  • uid313
    replied
    What about switching from C11 to C17?

    Or from gcc to cargo?

    Leave a comment:

Working...
X