VirtualBox SF Driver Ejected From The Linux 5.4 Kernel
Collapse
X
-
Originally posted by starshipeleven View PostAfaik yes. The developer said there is an "informal" agreement between him and the Virtualbox developers to try to keep the interface stable
Leave a comment:
-
-
Originally posted by Terrablit View Postit started before Oracle started squeezing people for VirtualBox licenses
Leave a comment:
-
-
Originally posted by caligula View PostHm, so is this driver even compatible with the userspace part of the stack?
Leave a comment:
-
-
Originally posted by caligula View PostHm, so is this driver even compatible with the userspace part of the stack?
Originally posted by NotMine999 View PostWho pushed this code to the kernel so late? Greg KH pull yet another stunt? Did a longtime Redhat Linux developer try to pull a fast one?
I wish whoever pushed this code to Linus would realize that Linux kernel development is not the place for: "It compiles this time! Ok, send it to Linus to merge it!"
Originally posted by Linus TorvaldsThis went into staging in rc7. It turns out that was a mistake, and apparently it wasn't even supposed to go there at all, but be introduced as a regular filesystem.
Leave a comment:
-
-
I don't understand why the Oracle proprietary file system code ever needs to be accepted into the mainline kernel. Microsoft accomplished the same goal of shared folders using the 9P filesystem driver already in the Linux kernel. 9P is used for this also by QEMU, KVM and Xen. VirtualBox already has a virtio transport implementation as an option for networking. They just need to extend their support for virtio to include 9P over virtio. Looking over the 3,200 lines of code that makes up vboxfs, this looks to just duplicate a subset of the functionality of 9P and contributes nothing new other than using Oracle proprietary method instead of an established open standard. The VirtualBox people are just being lazy in not supporting 9P as the shared folder protocol and have a history of also being lazy in maintaining the code they have gotten mainlined into the kernel in the past. Adding more duplicate functionality that will likely go stale and poorly maintained doesn't seem worth it.
Here is Oracle's 3200+ vboxfs patch:
Here is VirtualBox's documentation indicating the virtio transport is already an option for networking:
Here is the documentation for the existing 9P file system driver:
Here is a Microsoft blog post about doing shared folders via 9P:
The next Windows update is coming soon and we’re bringing exciting new updates to WSL with it! These include accessing the Linux file system from Windows, and improvements to how you manage and configure your distros in the command line. Accessing Linux files from Windows In the past, creating and changing Linux files from Windows […]
Here is the documentation for 9P with QEMU:
Here it is for KVM:
Here it is for Xen:
Anyone have a good reason why the kernel developers shouldn't tell Oracle to either use 9P or just use DKMS to add their proprietary file system driver? Is it likely that any other third party will ever make use of vboxsf instead of just using 9P in the future? Or will the vboxsf always be just a resource for one virtualization app from one company and never really be of generalized use beyond that? How can even MIcrosoft get this right and Oracle still claim they need their own method?
Seriously! Just use the well vetted and already available 9P client driver already in the kernel like everyone else!
Leave a comment:
-
-
Who pushed this code to the kernel so late? Greg KH pull yet another stunt? Did a longtime Redhat Linux developer try to pull a fast one?
I wish whoever pushed this code to Linus would realize that Linux kernel development is not the place for: "It compiles this time! Ok, send it to Linus to merge it!"
You would think that the people responsible for pushing code to Linus understand the basics of kernel development:- New code for the kernel goes through a review & approval process that can be time-consuming, but it's supposed to encourage better code quality.
- New code is supposed to be merged into a development tree with other new code in that major section of Linux, just to see how it all plays together.
- New code for the kernel should be pushed when the kernel "merge window" opens. Sometimes Linus allows later merges during RC0 and RC1, and sometimes not.
- Once new code has been merged during the "merge window", then it needs to be tested in the kernel with bugs supposedly getting fixed through multiple RC rounds.
- The new kernel is released when Linus is satisfied.
Leave a comment:
-
Hm, so is this driver even compatible with the userspace part of the stack?
Leave a comment:
-
-
Originally posted by cl333r View Post
Me too, too bad Linus isn't like Alex Jones.
Leave a comment:
-
Leave a comment: