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

  • #11
    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.

    Comment


    • #12
      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.

      Comment


      • #13
        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."

        Comment

        Working...
        X