Announcement

Collapse
No announcement yet.

ZFS On Linux Runs Into A Snag With Linux 5.0

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

  • pal666
    replied
    Originally posted by garegin View Post
    Just shows how weak the corporate support for Linux is.
    yep, ibm buying redhat for 34b is weak corporate support. or maybe it's just weak commenter's brain
    Originally posted by garegin View Post
    You have a dozen multi billion companies fawning over Linux and making money off it, but they can't get their asses in gear to finish a filesystem in 10 years.
    there is plenty of "finished" filesystems for linux. (i'm pretty sure you have no clue what that means but whatever)
    on the other hand there is bunch of crying idiots fallen to propaganda of obsolete by design zfs
    btw, why useless zfs imbeciles didn't finish upstreaming their filesystem?

    Leave a comment:


  • pal666
    replied
    Originally posted by Zan Lynx View Post
    If some kernel developers want to be silly about this then I'll be glad to dig out my grep, xargs, sed script that makes everything into ordinary EXPORT.

    I had to use it some time in 2007 for the Nvidia binary.
    correlation between nvidiots and zfs zealots

    Leave a comment:


  • pal666
    replied
    Originally posted by some_canuck View Post
    If going CDDL was hard enough for Sun back in the early 00's, you can imagine how much harder it will be in 2019 to go GPL.
    that's self-inflicted pain, nobody cares

    Leave a comment:


  • pal666
    replied
    Originally posted by k1e0x View Post
    Linux kernel dev's don't want it.. I'm sure FreeBSD will have no problem stealing Linux's market share with it.
    lol. how much did they steal during last decade?

    Leave a comment:


  • pal666
    replied
    Originally posted by pdffs View Post
    It's a shame that BTRFS turned out to be be such a steaming pile of crap, ZFS is the only filesystem of its kind worth using right now.
    it's a shame idiots have nothing to do but post bullshit

    Leave a comment:


  • pal666
    replied
    zfs is stable kokoko

    Leave a comment:


  • oiaohm
    replied
    Originally posted by GrayShade View Post
    Using SIMD to compute the checksums is fast enough and is not covered by patents with exceptions for GPL code. This isn't about hardware accelerators. It's about arbitrarily denying non-GPL modules access to SIMD. Do you believe it makes Linux better for anyone?
    I also missed another horrible fact. Using usermode-helper API to perform your SIMD or floating point stuff can in fact be faster than doing it in kernel space.

    It all todo with the nasty overheads of kernel_fpu_begin and kernel_fpu_end like you are locking the scheduler so that you cannot perform perform interrupts on that cpu core while you are in between those two and you need todo that because you are in 1 set of page tables the kernel space page tables. Switching to userspace you switch page tables this changes fpu and simd issue problems so you can run interrupts while in the usermode helper.

    1) usermode helper program does not have to be GPLv2 because its a normal program covered by Linus exception to gpl license.
    2) There is no demonstration of need. There is no driver demoed on the Linux kernel mailing list showing that usermode-helper will not meet their SIMD or FPU requirement.
    3) there has been no formal request until after the functions had been removed what is too late.

    Big thing here Linux kernel developers cannot be expected to be mind readers about what third party driver makers need or are using. Third party driver makers for Linux have a responsibility to be in the Linux kernel mailing list raising what they require. If they have not been in the Linux kernel mailing list attempting to get what they need I show them no mercy when function removal happens.

    Leave a comment:


  • GrayShade
    replied
    Originally posted by oiaohm View Post
    2003 form when __kernel_fpu_begin and __kernel_fpu_end entered kernel to 5.0 kernel there has been a open window to submit safe versions of these functions for non-GPL modules.
    kernel_fpu_begin and kernel_fpu_end were switched to GPL exports in this commit from 2015.

    This is so hopefully either you leave the Linux world or the next you hit something like this you get on the mailing list raise problem and get fixed before major issues.
    Yeah, careful with that...

    Leave a comment:


  • oiaohm
    replied
    Originally posted by GrayShade View Post
    Using SIMD to compute the checksums is fast enough and is not covered by patents with exceptions for GPL code. This isn't about hardware accelerators. It's about arbitrarily denying non-GPL modules access to SIMD. Do you believe it makes Linux better for anyone?
    The rules are the rules. The functions ZoL was using starting with __ is internal usage only really. The anyone use function by name is GPL only because is ABI/API has not been argued out.
    https://linux.slashdot.org/story/12/...nt-use-dma-buf

    People forget this stuff. Nvidia had to go trough quite along process to make interfaces so their closed source driver can use dmabuf.

    2003 form when __kernel_fpu_begin and __kernel_fpu_end entered kernel to 5.0 kernel there has been a open window to submit safe versions of these functions for non-GPL modules.

    It is possible EXPORT_SYMBOL_GPL to be convert to EXPORT_SYMBOL but this is not something that happens quickly. This means the function need to have its API debated and has to have a legal review. Like someone from 2008 to now from ZoL could have asked for the legal review and change on the Linux kernel mailing list. You can check the mailing list no one asked. If no one asks no must want the feature right GrayShade.

    Linux kernel developers are not mind readers. Linux kernel developers don't have unlimited amount of time for legal and code reviews either. Nvidia got their change by putting most of the slog work.

    Both __kernel_fpu_begin and __kernel_fpu_end are totally valid to be gone the request should have been done years ago to change kernel_fpu_begin and kernel_fpu_end GPL export to normal export. You have to ask if you are just doing SIMD why are you having to backup every single register of FPU and SIMD with these functions as well.

    Reality here the was work in mainline Linux kernel that those making kernel modules that are not GPL or mainline should have done.

    Yes EXPORT_SYMBOL_GPL or __ tag symbols should not be used in linux kernel modules that are not aiming to be part of the mainline linux kernel tree. If want you need to-do requires you to use those functions and you module is never mainline for licence or other reasons you really do need to be on the mailing list asking for solution.

    GrayShade like it or not the rules are the rules. Break them some point in future you will suffer. The __ rule on symbol was 1992 of the Linux kernel. The EXPORT_SYMBOL_GPL is newer but they both basically same thing. ZoL is in trouble now because it was using a pair of functions that it should not have been.

    Really I am feed up with my out of tree module broke because the Linux kernel changed and you look the problem is straight way using EXPORT_SYMBOL_GPL or __ . Yes your out of tree module broke but it you fault because you never told upstream that you need that function stable.

    The Linux kernel upstream is savage if you have told them that you need something well in advance of them removing it there could be a year or two of debates before they make what will remain long term. You leave it to where they have removed the function and it will be basically stuff you why are you tell us that you use that now. We don't have the time to make a proper interface so suffer. This is so hopefully either you leave the Linux world or the next you hit something like this you get on the mailing list raise problem and get fixed before major issues.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by k1e0x View Post
    My problem isn't the API change. I'm sure they will work that out. The issue is the emotional comments by Linux kernel dev's and the users.. whatever Sun's motivation. (and someone show me some proof they actually believed CDDL was not compatible, because it's was Debian that made that determination.) ..Whatever their motivation.. they are long since dead. Time to move on.
    https://sfconservancy.org/blog/2016/...zfs-and-linux/

    There have been many different legal reviews with CDDL compatibility with GPL. Most find it impossible to meet CDDL requirements and GPL requirements at the same time.

    I have not found one case where they say CDDL and GPL is 100 percent fine. The closest say due to the type of breach its not going to be enforceable in court. Problem is that is in a copyright court not a patent infringement count. Linux kernel is not just copyright. With OIN and other agreements to allow patented ideas into the Linux kernel under condition that is done under GPL means that a minor technical infringement of copyright comes a patent case of using a patented idea without a license so the harm and the problem.

    The funny part is ZFS is in fact under CDDL due to NetApp patent requirements. I think those patents might be now expired.

    Linux is a hair ball of copyright and patent license requirements.

    Leave a comment:

Working...
X