5 ms·

> If there is no "approved" method for creating Linux drivers under licenses other than the GPL, that seems like a major problem that Linux should be working to

> If there is no "approved" method for creating Linux drivers under licenses other than the GPL, that seems like a major problem that Linux should be working to address. The problem is already addressed: if someone wants to contribute code to the project then it's licensing must be compatible with the prior work contributed to project. That's it.

Wowfunhappy 7y ago
But why are all drivers expected to be "part of the project"? We don't treat userspace Linux software that way. We don't consider Windows drivers part of Windows.
- streb-lo 7y ago
  Because running proprietary binaries in kernel space is not a good idea nor is it compatible with the vision of Linux?
  - michaelmrose 7y ago
    ZFS isn't proprietary it's merely incompatible with the gpl.
- DSMan195276 7y ago
  It's pretty simple, once they expose such an API they'd have to support it forever, hindering options for refactoring (that happens all the time). With all the drivers in the tree, they can simply update every driver at the same time to whatever new in-kernel API they're rolling out or removing. And being that the majority of drivers would arguably have to be GPL anyway, and thus open-source, the advantages of keeping all the drivers in tree are high, and the disadvantages low. With that, they do expose a userspace filesystem driver interface, FUSE. There used to be a FUSE ZFS driver, though I believe it's mostly dead now (But I never used it, so I don't know for sure). While it's not the same as an actual kernel FS driver (performance in particular), it effectively allows what you're asking for by exposing an API you can write a filesystem driver against without it being part of the kernel code.
  - usefulcat 7y ago
    > With that, they do expose a userspace filesystem driver interface, FUSE. Yes, which Linus has also poo-pooed: "People who think that userspace filesystems are realistic for anything but toys are just misguided."
    - monocasa 7y ago
      I mean, he's right. VFS, VMM, and buffer cache are all three sides of the same coin. Nearly every system that puts the FS in user space has abysmal performance; the one exception I can think of off the top of my head is XOK's native FS which is very very very different than traditional filesystems at every layer in the stack, and has abysmal performance again once two processes are accessing the same files.
      - usefulcat 7y ago
        Oh, I totally agree. But between that statement and this one about ZFS, the takeaway seems to be: for filesystems on Linux, go GPL or go home. Which is fine if that's his attitude, but if so I do wish he'd be more direct about it rather than making claims that are questionable at best (e.g. "ZFS is not maintained"--wtf?).
    - AnIdiotOnTheNet 7y ago
      And yet people use them all the damn time because they're incredibly useful and even more importantly are relatively easy to put together compared to kernel modules. Linus is just plain wrong on this one.
      - DSMan195276 7y ago
        You should read the full quote, he really doesn't disagree with you: > fuse works fine if the thing being exported is some random low-use interface to a fundamentally slow device. But for something like your root filesystem? Nope. Not going to happen. His point is that FUSE is useful and fine for things that aren't performance critical, but it's fundamentally too slow for cases where performance is relevant.
- ordu 7y ago
  > But why are all drivers expected to be "part of the project"? We don't treat userspace Linux software that way. It is the policy of linux development at work. Linux kernel doesn't break userspace, you could safely upgrade kernel, your userspace would work nice. But Linux kernel breaks inner APIs easily, and kernel developers take responsibility for all the code. So if a patch in memory management subsystem broke some drivers, kernel developers would find breakages and fix them. > We don't consider Windows drivers part of Windows. Yeah, because Windows kernel less frequently breaks backward compatibility in kernel space, and because hardware vendors are ready to maintain drivers for Windows.
- rumanator 7y ago
  You can license both kernel modules or FUSE implementation any way you see fit. That's a non-issue. https://www.kernel.org/doc/html/latest/process/license-rules.html https://www.kernel.org/doc/html/latest/process/license-rules... It seems that some people are oblivious to the actual problem, which is some people want their code to be mixed into the source code of a software project without having to comply with the rightholder's wishes, as if their will shouldn't be respected. > We don't consider Windows drivers part of Windows. I'm not sure you can commit your source code to the windows kernel project.
  - dathinab 7y ago
    No, no one wants to force ZFS into the Linux kernel. I think anyone agrees that it needs to be out-of tree the way thinks are currently. The problem is the nature of changes, and people questioning if there is any good _technical_ reason why some of the changes need to be the way they are done.

Wowfunhappy 7y ago

But why are all drivers expected to be "part of the project"? We don't treat userspace Linux software that way. We don't consider Windows drivers part of Windows.

streb-lo 7y ago
Because running proprietary binaries in kernel space is not a good idea nor is it compatible with the vision of Linux?
- michaelmrose 7y ago
  ZFS isn't proprietary it's merely incompatible with the gpl.
DSMan195276 7y ago
It's pretty simple, once they expose such an API they'd have to support it forever, hindering options for refactoring (that happens all the time). With all the drivers in the tree, they can simply update every driver at the same time to whatever new in-kernel API they're rolling out or removing. And being that the majority of drivers would arguably have to be GPL anyway, and thus open-source, the advantages of keeping all the drivers in tree are high, and the disadvantages low. With that, they do expose a userspace filesystem driver interface, FUSE. There used to be a FUSE ZFS driver, though I believe it's mostly dead now (But I never used it, so I don't know for sure). While it's not the same as an actual kernel FS driver (performance in particular), it effectively allows what you're asking for by exposing an API you can write a filesystem driver against without it being part of the kernel code.
- usefulcat 7y ago
  > With that, they do expose a userspace filesystem driver interface, FUSE. Yes, which Linus has also poo-pooed: "People who think that userspace filesystems are realistic for anything but toys are just misguided."
  - monocasa 7y ago
    I mean, he's right. VFS, VMM, and buffer cache are all three sides of the same coin. Nearly every system that puts the FS in user space has abysmal performance; the one exception I can think of off the top of my head is XOK's native FS which is very very very different than traditional filesystems at every layer in the stack, and has abysmal performance again once two processes are accessing the same files.
    - usefulcat 7y ago
      Oh, I totally agree. But between that statement and this one about ZFS, the takeaway seems to be: for filesystems on Linux, go GPL or go home. Which is fine if that's his attitude, but if so I do wish he'd be more direct about it rather than making claims that are questionable at best (e.g. "ZFS is not maintained"--wtf?).
  - AnIdiotOnTheNet 7y ago
    And yet people use them all the damn time because they're incredibly useful and even more importantly are relatively easy to put together compared to kernel modules. Linus is just plain wrong on this one.
    - DSMan195276 7y ago
      You should read the full quote, he really doesn't disagree with you: > fuse works fine if the thing being exported is some random low-use interface to a fundamentally slow device. But for something like your root filesystem? Nope. Not going to happen. His point is that FUSE is useful and fine for things that aren't performance critical, but it's fundamentally too slow for cases where performance is relevant.
ordu 7y ago
> But why are all drivers expected to be "part of the project"? We don't treat userspace Linux software that way. It is the policy of linux development at work. Linux kernel doesn't break userspace, you could safely upgrade kernel, your userspace would work nice. But Linux kernel breaks inner APIs easily, and kernel developers take responsibility for all the code. So if a patch in memory management subsystem broke some drivers, kernel developers would find breakages and fix them. > We don't consider Windows drivers part of Windows. Yeah, because Windows kernel less frequently breaks backward compatibility in kernel space, and because hardware vendors are ready to maintain drivers for Windows.
rumanator 7y ago
You can license both kernel modules or FUSE implementation any way you see fit. That's a non-issue. https://www.kernel.org/doc/html/latest/process/license-rules.html https://www.kernel.org/doc/html/latest/process/license-rules... It seems that some people are oblivious to the actual problem, which is some people want their code to be mixed into the source code of a software project without having to comply with the rightholder's wishes, as if their will shouldn't be respected. > We don't consider Windows drivers part of Windows. I'm not sure you can commit your source code to the windows kernel project.
- dathinab 7y ago
  No, no one wants to force ZFS into the Linux kernel. I think anyone agrees that it needs to be out-of tree the way thinks are currently. The problem is the nature of changes, and people questioning if there is any good _technical_ reason why some of the changes need to be the way they are done.