Hey all,

A couple months ago in July, I talked about making a kernel. Believe it or not, kernels are some of the most complex pieces of software and making one is extremely difficult. Additionally, writing one from the ground up isn't very practical. I'm not abandoning this goal, however I no longer think it makes sense to pause development of major features while working on something that could take years. Rather than write an entire kernel, the code infrastructure needed for features will be developed alongside those features incrementally.

With that in mind, here is the roadmap for major changes and features, in no particular order:

"Kernel" modules, sysfs

The simple device driver API ZenFS has seen some adoption. Unfortunately, this API isn't powerful enough. In order to support sysfs, we need to have something like kobjects, which means an upgrade to the device driver API is in order.

This API for kernel modules will be very composable, and could have much broader uses beyond the file system. This complicates deciding where to implement it:

• If it is implemented in @zenfs/core, users will need to pull in all the FS code. This would result in marginally better maintainability while sacrificing modularity.
• If it is implemented in Kerium, the API can be used for many other uses cases (like device emulation) without having to pull in 800KB of other code. While this does separate concerns better, the result is maintaining the feature across two codebases.

@konsumer and @mathiscode are the two biggest users of device drivers and the like. If either of you have some feedback on this, please let me know!

Mount Namespaces

There is clearly a need for advanced use cases to have separate sets of mounts. In the future, ZenFS will support specifying a namespace for mounts used by a context. @jeff-hykin has done a lot of really cool work in this area as part of #218, so this will hopefully come sometime soonish.

procfs (/proc)

This won't be as feature complete as the real one on Linux, but I think we can have something reasonable implemented. This would expose metadata about existing FS contexts, and shouldn't be terribly difficult to implement. For backwards compatibility this would probably be behind a flag in Configuration (e.g. procfs: true)

UNIX Domain Sockets, FIFO

I haven't looked into these enough to give a clear plan of how they will be implemented. Supporting these other file types would make ZenFS more powerful and feature complete though, so it's worth me taking a look at. No guarantees though.

Other hosts (?)

I've been considering whether we could implement compatibility for the FS APIs of other major JS hosts, like Deno and Bun. This would be contingent on enough community interest.

Feedback

As always, any and all feedback is welcome. Please feel free to drop a comment below!

Updates

16 November 2025: Work on a "kernel" module API is coming along well. I plan on releasing this as a separate package, @zenfs/linux.