Bcachefs Fixes Pull Once Again Frustrates Linus Torvalds - Two Choices Offered

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • oleid
    Senior Member
    • Sep 2007
    • 2544

    Originally posted by Developer12 View Post

    Hopelessly inadequate testing when it doesn't even compile for a lot of people. Literally. His patches didn't even build on any of the BE arches.
    I think you mixed something up here. You logically connected "a lot of people" with "big endian". Those two don't go together.

    But as you most certainly read in the following discussion, they are discussing big endian ci. So it will get solved.

    Comment

    • Daktyl198
      Senior Member
      • Jul 2013
      • 1593

      Originally posted by mdedetrich View Post

      And as pointed out numerous times before. Kent didn't break the kernel build, others did. The one time he did break it accidentally, it was for an architecture that almost no one uses (big endien based systems like motorola and IBM-z).
      IBM-z is a very popular line of products, with quite a few users. I've run into it more in the last year than I have any time before, even. So it's definitely an important build target.

      Comment

      • Mathias
        Senior Member
        • Nov 2009
        • 238

        I'm not sure this has been answered. The BIg Endian Build failure, did it show up when cross compiling from x86 or was it a build failure only if you compiled on BE?

        Comment

        • mdedetrich
          Senior Member
          • Nov 2019
          • 2551

          Originally posted by fitzie View Post

          Do you have some sort of reading deficiency? kent is working on *his* CI tool, not the CI, he's the primary person working on his own thing he keeps saying nothing else exists, which is plainly not true. I've said multiple times that I have nothing against CI, just that talk about CI is a distraction from the real issue.
          Yes and as he said in the mailing list, the other CI tools are not even public (or only their results are public but not the ability to modify the CI for the needs of the users). Thats why he is forced to make his own.

          For example there is a public CI tool for testing XFS, as posted in the mailing list. But it only tests XFS, which is not useful for bcachefs, there is no public way to modify it so it can also test bcachefs.

          Originally posted by fitzie View Post
          None of his problems with dealing with other kernel developers politely goes away if some new CI pops up. I'm defending the process not because it's old and the stupidest possible way, because it's how other developers expect to interact with maintainers. that they can just look up a patch in lore (or wherever) and find the thread that discuss that patch. If that's stupid fine, that's not a good reason to kent not to follow it, after being asked multiple times by people specifically looking to discuss issues with those patches with him (not as kent said just by people trying to enforce silly rules).
          You are arguing with yourself now, you half heartadly admitted that the process is stupid without going the full way and admitting that the core problem is the process.

          What I said before is right, process'es are not some god given commandment. if they are stupid and don't fullfill their purpose well then they need to change, and they change in response to people like Kent who have literal zero tolerance to this kind of bs.

          Originally posted by fitzie View Post
          even if kent is right about all this process stuff, he's not helping his project being so bad at working with others. that's been my point since bcachefs submission time last year. If that's putting linus on a pedestal, then I'll just have to accept that accusation. But the list of people Kent has gone to war with is long and growing. I can only hope they don't hold grudges against him, like he's stated he holds on them.
          The only people that Kent has an issue with are the ones that have an ego that is literally bigger than his which are purpetuating the problem. I mean the fact that Linus actually backed down says a lot, he realized that basically he went way overboard with abusing/yelling at Kent without realizing that Kent was acting the way he was because he was at his limits and was literally being scapeboating for issues he didn't even cause.

          Like you have glossed over/conveniently ignored the fact that in one case Linus accused Kent of breaking the build, but that wasnt even his fault, that was Christians that introduced a change to VFS which broke bcachefs because he forgot to update bcachefs at the same time.

          Comment

          • mdedetrich
            Senior Member
            • Nov 2019
            • 2551

            Originally posted by anarki2 View Post

            How do you end up with a build failure while "testing" then, please explain.
            Try buying/getting a big endian machine and then get back to me.

            Incase you still don't get it, unless you are talking about stuff like ibm-z machines which are literally mainframes (you know those massive big machines in data centers), companies have stopped manafacturing big endian machines literally many decades ago.

            Hence the only somewhat practical way to test for big endian is by virtualizing it through qemu, but as Kent pointed out correclty at https://lore.kernel.org/lkml/dcfwznp...@rjon67szaahh/ those tests require an extortionate amount of time to run because they have to be entirely emulated (again because its a completely different architecture that no one builds anymore)
            Last edited by mdedetrich; 07 October 2024, 03:09 AM.

            Comment

            • User29
              Senior Member
              • Dec 2023
              • 253

              Originally posted by mdedetrich View Post

              And as pointed out numerous times before. Kent didn't break the kernel build, others did. The one time he did break it accidentally, it was for an architecture that almost no one uses (big endien based systems like motorola and IBM-z).
              What? Even though it is an arch noone uses, if it's in the CI then it is in the CI. If others can live with it, then Ken should be able too. Maybe this was just a minor mistake but he has such a history that probably Linux grew impatient to see him causing problems again.

              Originally posted by mdedetrich View Post
              Also if breaking the build is such a big problem, maybe Linus should do something useful and instead of ranting on lkml, use the funds from the Linux foundation to setup a CI that builds the kernel on a frequent basis (usually nightly), especially if he is going to make such a big deal out of the kernel not building on machines that are literally many decades old.
              Goto 1

              Originally posted by mdedetrich View Post
              Oh wait, Kent is doing that because he is mature and actually taking up ownership for the problem instead of yelling at others.
              Joke of the week.

              Although I was kind of excited to see bcachefs included in the kernel "early" and I was convinced that it would help it's development, now I'm pretty sure that the gap between the two development models is too big. bcachefs should be DKMS ready (if it's not already is) and should be shipped like that, and when it's mature and there aren't so many changes in it, then it could be imported into the mainline.

              The question is, what would happen if Linus drops bcachefs.
              (a) Kent learns his lesson and comes back later, starts to behave and aligns to the rules
              (b) Kent will never come back because of hurt ego

              In both cases he may lose sponsors and fundings.

              Comment

              • PuckPoltergeist
                Senior Member
                • Jan 2009
                • 477

                Originally posted by Uiop View Post

                I don't see it that way. Kent is developing his filesystem alone, a lot of problems are cropping up, and he is solving them and communicating with other Linux developers.

                Perhaps Kent's social skills are terrible, perhaps not. Anyway, why should someone's social skills be the issue of such a high importance? Why should other Linux developers act aggressively just because Kent has terrible social skills?

                Aren't Linux developers grown-ups? Is it so hard to tolerate Kent's whacky-ness?

                I don't see any mischiefs of high importance in Kent's communications.
                All I see is a clickbait article on Phoronix, and a lot of people on this forum who couldn't wait to jump on Kent.
                If someone comes around, telling he's the only one who is doing right, all the others are just building crap and everybody has to follow him, yes it's really hard to tolerate this behavior.

                Comment

                • mdedetrich
                  Senior Member
                  • Nov 2019
                  • 2551

                  Originally posted by User29 View Post

                  What? Even though it is an arch noone uses, if it's in the CI then it is in the CI. If others can live with it, then Ken should be able too. Maybe this was just a minor mistake but he has such a history that probably Linux grew impatient to see him causing problems again.
                  Read the fuking mailing list, its not in the nightly fs-next CI, thats precisely the issue

                  https://lore.kernel.org/lkml/dcfwznpfogbtbsiwbtj56fa3dxnba4aptkcq5a5buwnkma76nc @rjon67szaahh/

                  Originally posted by User29 View Post
                  The question is, what would happen if Linus drops bcachefs.
                  (a) Kent learns his lesson and comes back later, starts to behave and aligns to the rules
                  (b) Kent will never come back because of hurt ego

                  In both cases he may lose sponsors and fundings.
                  Maybe you should actually read what people are saying on the mailing list. Linus just made a new response and he backed down after he realized most of the things he was accusing Kent of weren't actually his fault.

                  He even suggested alternative processes (the original process that so many people were claiming was a rule, Linus actually clarified was a guideline that happened to work well with another subsystem, namely networking) while still trying to suggest his own timing rule.

                  The core issue that Linus cares about is builds not breaking but unfortunately the current setup in Linux is insanely antiquitated and primitive and is only really practical for one way of working, i.e. currently existing features that are basically in maintanence mode. For code that is evolving as fast as bcachefs, being only able to find out once every 3 months that your code doesn't build on an architecture which literally no one manufacturers anymore is a fuken terrible way to work, it should be a nightly CI run.

                  Linux foundation presumabely has a big endian mainframe like a s390x or something similar, they should put that mainframe to good use and build the kernel nightly to detect any build issues.
                  Last edited by mdedetrich; 07 October 2024, 04:09 AM.

                  Comment

                  • NobodyXu
                    Senior Member
                    • Jun 2021
                    • 815

                    The comment section is getting toxic and political very quick...

                    people are pointing fingers at Kent for being childish, initially I do think Kent are probably at fault, but once I noticed that it is a problem with BE and IBM-Z I knew this is a hard-to-catch issue.

                    It is hard to do cross compilation, don't say something like "others can tolerate, so it must be your fault", getting CI/cross compilation/testing to work is damn hard.

                    These extra political pointing does not help improve stuff, like with better process/CI.

                    Comment

                    • mdedetrich
                      Senior Member
                      • Nov 2019
                      • 2551

                      Originally posted by Uiop View Post
                      Here is a question, one thing I don't understand.

                      The well-known big-endian architectures are: 68000, IBM System/360, z/Architecture and OpenRISC.
                      Aside from OpenRISC, all of those other architectures are either mainframes or insanely old (the motorola 68000 is from 1979). Judging from wikipedia, OpenRISC has only really been used to build fgpa's, not suitable for kernel testing where you need to test every subsystem https://en.wikipedia.org/wiki/OpenRISC

                      Originally posted by Uiop View Post
                      But, some other architectures are bi-endian, or some other strange mix of endianess, like: PowerPC (per-page choice), ARM AArch64 (instruction encoding, little endian by default otherwise).

                      Wikipedia says: "Some architectures (including ARM versions 3 and above, PowerPC, Alpha, SPARC V9, MIPS, Intel i860, PA-RISC, SuperH SH-4 and IA-64) feature a setting which allows for switchable endianness in data fetches and stores, instruction fetches, or both."

                      So, why is it not possible to buy an ARM CPU, and use it in the big-endian mode to do the big-endian tests? Or, a PowerPC?
                      I would presume that for some technical reason this doesn't cut it

                      Originally posted by Uiop View Post
                      Or, is it just that such a big-endian test system is not yet available for the Linux kernel? I guess that is the real issue here.

                      If the kernel doesn't have automated builds and tests in big-endianess mode, it's their own fault.
                      From what I have read online, the Linux foundation has a 1990's s390x mainframe that makes kernel builds but it only does the build on RC submission which is once every 3 months. This is insanely impractical for development. Pretty much every open source, if they claim to support an architecture will actually do nightly builds on every architecture, Rust for example does it this way.

                      Thats what Kent is trying to explain/fix, he is also setting up a CI to test against fs-next (which is basically the "nightly" for the filesystem subsystem for linux kernel).

                      Comment

                      Working...
                      X