-- Leo's gemini proxy
-- Connecting to gemini.tuxmachines.org:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;lang=en-GB
Tux Machines
Posted by Roy Schestowitz on Mar 05, 2023
> The 6.2 kernel was released on February 19, at the end of a ten-week development cycle. This time around, 15,536 non-merge changesets found their way into the mainline repository, making this cycle significantly more active than its predecessor. Read on for a look at the work that went into this kernel release.
> The work in 6.2 was contributed by 2,088 developers, which just barely sets a new record; the previous record was the 2,086 developers contributed to 5.19. Of those developers, 294 made their first contribution to the kernel in this cycle, a fairly typical number.
> The splice() system call is built on an appealing idea: connect two file descriptors together so that data can be moved from one to the other without passing through user space and, preferably, without being copied in the kernel. splice() has enabled some significant performance optimizations over the years, but it has also proved difficult to work with and occasionally surprising. A recent linux-kernel discussion showed how splice() can cause trouble, to the point that some developers now wonder if adding it was a good idea.
> Stefan Metzmacher is a Samba developer who would like to use splice() to implement zero-copy I/O in the Samba server. He has run into a problem, though. If a file is being sent to a remote client over the network, splice() can be used to feed the file data into a socket; the network layer will read that data directly out of the page cache without needing to make a copy in the kernel — exactly the desired result. But if the file is written before network transmission is complete, the newly written data may be sent, even though that write happened after the splice() call was made, perhaps even in the same process. That can lead to unpleasant surprises (and unhappy Samba users) when the data received at the remote end is not what is expected.
> When LWN looked at the composefs filesystem in December, we reported that there had been "little response" to the patches. That is no longer the case. Whether composefs (or something like it) should be merged has become the subject of an extended debate; at its core, the discussion is over just how Linux should support certain types of container workloads. Composefs is an interesting sort of filesystem, in that a mounted instance is an assembly of two independent parts. One of those, an "object store", is a directory tree filled with files of interest, perhaps with names that reflect the hash of their contents; the object store normally lives on a read-only filesystem of its own. The other is a "manifest" that maps human-readable names to the names of files in the object store. Composefs uses the manifest to create the filesystem that is visible to users while keeping the object store hidden from view. The resulting filesystem is read-only.
> This mechanism is intended to create the system image for containers. When designing a container, one might start with a base operating-system image, then add a number of layers containing the packages needed for that specific container's job. With composefs, the object store contains all of the files that might be of interest to any container the system might run, and the composition of the image used for any specific container is done in the manifest file. The result is a flexible mechanism that can mount a system image more quickly than the alternatives while allowing the object store to be verified with fs-verity and shared across all containers in the system.
> We discussed the "landlock" security feature in the forum:
> https://forum.puppylinux.com/viewtopic.php?t=8023
> Up until now, the kernel in Easy has left out user-namespace support due to some perceived security issue. Though, that is a vague concern, and after reading recently that Vivaldi needs that kernel feature when run non-root, I decided to enable it.
-- Response ended
-- Page fetched on Thu Jun 13 21:53:29 2024