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

  • evasb
    replied
    Originally posted by Mario Junior View Post

    So these guys make a reversal engineer and create a ntfs driver without ms code?
    NTFS is not patented, MS just didn't release the code. Paragon did a NTFS driver on their own, sold it for Mac/Linux users (https://www.paragon-software.com/us/...professional/#) now they are contributing their driver back to Linux upstream.

    Leave a comment:


  • set135
    replied
    Just an update on the ntfs3 driver; Paragons developer has responded to Linus and offered to prepare a pull request, which he sounded willing to pull during the next merge window, and meantime recommended it to linux-next.

    http://lkml.iu.edu/hypermail/linux/k...7.3/07429.html

    Leave a comment:


  • Mario Junior
    replied
    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?

    Leave a comment:


  • rbmorse
    replied
    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...

    Leave a comment:


  • intelfx
    replied
    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.

    Leave a comment:


  • Nocifer
    replied
    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.

    Leave a comment:


  • mdedetrich
    replied
    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.

    Leave a comment:


  • Weasel
    replied
    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.

    Leave a comment:


  • evasb
    replied
    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.

    Leave a comment:


  • Nocifer
    replied
    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.

    Leave a comment:

Working...
X