Jump to content

Talk:File system API

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Claunia (talk | contribs) at 15:06, 1 February 2007 (→Rewrite). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)[reply]

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.

In kernel-level the filesystem driver is in the SAME OBJECT FILE AND PROCESS as the rest of the kernel components. In driver-level it is in kernel mode, but it is loaded as a library. Check OS/2 and Windows NT IFS's and you will see the differences.

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?

You are absolutely wrong. See "win.com /?" and you'll see it runs by default IN PROTECTED MODE. And of course, you can run it in real mode, then you can see in the control panel that you can't use the VFAT driver (it is called 32-bit disk access). If you need I can provide you with screenshots.
Of course Windows 9x API is the same as Windows 3.1, just evolved (as the Windows Vista evolved from Windows NT 3.5)

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 (!?).

User space APIs are incompatible between them. You cannot use the ADFLIB or the HFSUTILS drivers in FUSE, not reverse. You must recompile or adapt them to work at all.

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)[reply]


Answering the article comments:
What does "originally" mean? NFS appeared in 1984, first network file systems were developed in the 1970s, see distributed file system — User:Intgr
There were operating system before 1984 and before 1970s and first networks. You can also check in UNIX source code that VFS was added to support NFS.
Huh? File system code is still part of the kernel on common operating systems these days. — User:Intgr+
Of monolithic kernels? Yes, of modular or microkernels, they aren't. E.g.: The NT kernel needs to load a filesystem driver for EVERY filesystem (FAT, NTFS, ISO9660, UDF) for being able to read them.
Apart from that, current monolithic kernels also use a filesystem API. Before that kernels when requested to open a file DIRECTLY opened it (see DOS 1.0 for example), currently they use their filesystem API to communicate with the correct filesystem code (being network or disk), and then that code is the one that directly opens it.
FIXME: Again, what's the "originally" above? I think this one contradicts with the listing of Unix under "kernel-level APIs", below. Unix predates most operating systems that are considered "old" that people still know of today — User:Intgr
Again, check the UNIX source archives. There are also hundreds of disk operating systems that predates UNIX.
If you have more doubts feel free to email me.
Regards, —Claunia 15:06, 1 February 2007 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:File_system_API&oldid=104849669"