On Jan 26, 2021, at 09:25, Amy Parker <enbyamy@xxxxxxxxx> wrote: > > Kernel development newcomer here. I've begun creating a concept for a > new filesystem, and ideally once it's completed, rich, and stable I'd > try to get it into the kernel. Hello Amy, and welcome. I guess the first question to ask is what would be unique and valuable about the new filesystem compared to existing filesystems in the kernel? Given that maintaining a new filesystem adds ongoing maintenance efforts, there has to be some added value before it would be accepted. Also, given that filesystems are storing critical data for users, and problems in the code can lead to data loss that can't be fixed by a reboot, like many other software bugs, it takes a very long time for filesystems to become stable enough for general use (the general rule of thumb is 10 years before a new filesystem is stable enough for general use). Often, if you have ideas for new functionality, it makes more sense to add this into the framework of an existing filesystem (e.g. data verity, data encryption, metadata checksum, DAX, etc. were all added to ext4). Not only does this simplify efforts in terms of ongoing maintenance, but it also means many more users will benefit from your development effort in a much shorter timeframe. Otherwise, users would have to stop using their existing filesystem before they started using yours, and that is a very slow process, because your filesystem would have to be much better at *something* before they would make that switch. > What would be the process for this? I'd assume a patch sequence, but > they'd all be dependent on each other, and sending in tons of > dependent patches doesn't sound like a great idea. I've seen requests > for pulls, but since I'm new here I don't really know what to do. Probably the first step, before submitting any patches, would be to provide a description of your work, and how it improves on the current filesystems in the kernel. It may be that there are existing projects that duplicate this effort, and combining resources will result in a 100% done filesystem rather than two 80% done projects... Note that I don't want to discourage you from participating in the Linux filesystem development community, but there are definitely considerations going both ways wrt. accepting a new filesystem into the kernel. It may be that your ideas, time, and efforts are better spent in contributing to an exiting project. It may also be that you have something groundbreaking work, and I look forward to reading about what that is. Cheers, Andreas
