Talk:File system API
there are different examples that can be added:
- linux FUSE architecture
- full userspace architectures such as:
- the HURD
- Feel free to register in wikipedia and enhance the article (and please sign up your comments in talk pages)
- —Claunia 09:10, 9 September 2006 (UTC)
Rewrite
This article is in a serious need of a rewrite. I rewrote the lead section to be technically correct, but I don't really know what to make of the history section (I left a comment for each paragraph there), and I pretty much gave up when I reached the next one. The article often uses very vague terminology, and the criteria for current classifications are unintelligible.
What's the difference between "kernel-level" (formerly "kernel-based") and "driver-level" APIs? The article currently says "The API is "driver-based" when the kernel provides facilities but the filesystem code resides totally external to the kernel (not even as a module of a modular kernel).", but how can a piece of code execute in kernel mode without being included in the kernel, nor loaded as a module? Windows NT file systems certainly execute in kernel mode.
From there follows the "Mixed kernel-driver-based API". Obviously I can't understand that, as it relies on the previous definition. As Windows 3.1 inherently ran in real mode, there is no actual entity called a "kernel" to speak of, just some code that happens to interface with hardware. The description seems to imply that Windows 95 file systems were wrapped for compatibility, but the file system still implements the Windows 95 file system driver API. If it's the Windows 95 API, then how is this really any different from the preceding two?
The "user space API" (formerly "userland-level API") is refreshingly understandable; however, it fails to be informative and somewhy claims that all user space filesystem APIs are inherently incompatible (!?).
If you take all that away, there is not much left at all. Thus I decided not to do it at this point. -- intgr 21:31, 12 December 2006 (UTC)