Announcement

Collapse
No announcement yet.

Paragon's NTFS Driver For The Linux Kernel Spun Up A 27th Time

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

  • #21
    birdie I Inderstand your Point, but I, like the Kernel devs, wouldn't want to have code just because it works if I would have to support it with bad indentation, misuse of functions etc.

    Comment


    • #22
      Originally posted by baka0815 View Post
      birdie I Inderstand your Point, but I, like the Kernel devs, wouldn't want to have code just because it works if I would have to support it with bad indentation, misuse of functions etc.
      I think birdie is right here, in this case the kernel dev's kinda fuked up. In this situation if I can't actually provide a better alternative I would have just merged the code and then one can improve on it iteratively later.

      Also improving on someone else coded to get it merged isn't unheard of in open source development and I don't know why people are giving it the negative connotation that they are (especially if the guys don't provide an alternative).

      Code style is obviously something that the contributor should fix though

      Comment


      • #23
        Originally posted by evasb View Post

        https://www.spinics.net/lists/linux-hwmon/msg11260.html

        WTF, the guy tried to upstream the patch, got rejected ("don't want to use ifdefs"), the guy asked for suggestions and the maintainer's response was "NO IDEA".

        No wonder Bernhard Seibold doesn't want to work on it anymore
        No, the maintainer's response was neither "don't want to use ifdefs"...

        Originally posted by Maintainer
        No, this makes the driver unmaintainable. There should be a separate driver which only makes WMI/ACPI accesses for everything.

        Guenter
        nor "NO IDEA":

        Originally posted by Maintainer
        No idea, quite frankly. Sprinkling the driver with ifdefs and conditional code for sure isn't the solution. You might consider dropping the ifdefs and use dmi detection instead, possibly with a module parameter to bypass the dmi detection. I'd rather have no ifdefs and miss some platforms where this is untested.

        You could try by splitting the single patch into several patches, with one or more preparatory patches, and maybe write accessor functions to avoid the runtime conditonals. Oh, and don't use C++ comments.

        Guenter
        As you can see, the maintainer's responses actually contain a fair few suggestions which the patch creator chose to ignore and instead decided to not work on his patch anymore.

        It's always fun taking things out of context and even putting unsaid things in quotes ("don't want to use ifdefs") in order to make reality fit with your point of view, eh?

        In other news, birdie is back from his long-term vacation and it's like his posts have been perfectly preserved in time. Same old, same old.

        Comment


        • #24
          Originally posted by Nocifer View Post
          ...
          I apologize for putting "unsaid things" in quotes, but this is the Maintainer's point.

          He is technically right on this, but is pretty sad how unfriendly it is to contribute to the kernel today. It's like contributing to the kernel is only for big tech employees that can endure the stress of refactoring their code many times and maintainers that can't give clear directions [no idea, but you can try this, this, this or maybe this?] to the first-timer contributor to make their, hopefully, first of many successful PRs.

          I don't feel any fun on this.

          Comment


          • #25
            Originally posted by birdie View Post
            I'm talking about how difficult is to get your code merged despite the proclamations that it's open source and everyone is welcome to contribute. Not only you're not welcome, you have to work your buttocks off to be accepted. It's the 27th revision of the NTFS code - how crazy it is?

            Never mind, I'm an old geezer and I'm talking BS. Linux is perfect, it perfectly supports everything and it has a ton of perfect software for it.
            At least he got reviews unlike some other open source projects.

            Comment


            • #26
              Originally posted by evasb View Post

              I apologize for putting "unsaid things" in quotes, but this is the Maintainer's point.

              He is technically right on this, but is pretty sad how unfriendly it is to contribute to the kernel today. It's like contributing to the kernel is only for big tech employees that can endure the stress of refactoring their code many times and maintainers that can't give clear directions [no idea, but you can try this, this, this or maybe this?] to the first-timer contributor to make their, hopefully, first of many successful PRs.

              I don't feel any fun on this.
              To put it another way, being right isn't always the same as being helpful and this is a good example of this.

              Comment


              • #27
                Originally posted by evasb View Post

                I apologize for putting "unsaid things" in quotes, but this is the Maintainer's point.

                He is technically right on this, but is pretty sad how unfriendly it is to contribute to the kernel today. It's like contributing to the kernel is only for big tech employees that can endure the stress of refactoring their code many times and maintainers that can't give clear directions [no idea, but you can try this, this, this or maybe this?] to the first-timer contributor to make their, hopefully, first of many successful PRs.

                I don't feel any fun on this.
                Well the thing is, in this specific case I get the impression that the maintainer simply doesn't find the patch/functionality important enough to warranty him stepping in his dev shoes and trying to fix the patch himself. I mean, even AMD themselves don't seem to consider it a priority, otherwise they'd have already implemented it. He did provide some generic advice and guidelines though, but then left it to the patch creator to refactor the patch.

                On the other hand, it's the patch creator who (AFAICT from that exchange I read) never responded to the advice and guidelines, and my impression on that was not that he was a first time contributor who simply became overwhelmed with the responsibility, but rather a guy who was too lazy to refactor the patch in a proper and maintainable way, again, as per the advice and guidelines provided. Now, I do realize the need for the functionality (I myself have an ASUS X470 mobo that currently utilizes an out-of-tree WMI driver for reading sensors) but that doesn't mean we should be turning the kernel into another X11 spaghetti festival. As a previous commenter said, open source does not mean low standards (or hacky solutions, if I may add).

                As a final note, indeed, the Linux kernel today is more an enterprise product and less a CS student's hobby project. This has both advantages and disadvantages, but I really do not consider not accepting hacky patches that do not conform to the kernel standards as a disadvantage. And if the maintainer is simply being a moron and the patch is in fact good (disclaimer: I haven't seen it), then why doesn't the author simply send a mail to Linus and ask him to intervene? I mean, we're still talking about an open source kernel here.

                Comment


                • #28
                  Originally posted by tildearrow View Post
                  Are we talking about NTFS or about sensors?

                  Where are you guys?
                  We're talking about both. It's notoriously hard to get your code into kernel if it's not server stuff backed by some large corp.

                  Comment


                  • #29
                    Originally posted by intelfx View Post

                    We're talking about both. It's notoriously hard to get your code into kernel if it's not server stuff backed by some large corp.
                    Lets ask Con Kolivas for his opinion...

                    Comment


                    • #30
                      Originally posted by evasb View Post

                      Because their NTFS driver doesn't have any MS code, it's a clean room implementation.

                      They need to just do a pull request already.
                      So these guys make a reversal engineer and create an ntfs driver without ms code?

                      Comment

                      Working...
                      X