W - Revision history

Lundman: Blanked the page

2017-05-18T08:44:40Z

Blanked the page

Lundman at 08:44, 18 May 2017

2017-05-18T08:44:04Z

Lundman: You cant tell me what to do

2017-05-15T11:58:45Z

You cant tell me what to do

New page

== Windows Port ==

Until it has its own space, I am using this space to jot down some of the findings.

All the IO Request Packets (IRP) all come in through the same set of function handlers, which can get a bit noisy. So ioctls from userland to, say, listing datasets, come in to the same place, as requests to list a directory, and volume creation notifications, etc etc. It gets a bit noisy.

To trigger a mount, we add two new ZFS ioctls, for mount and unmount. In mount we will create a new fake disk, then create a filesystem that we attach to the fake disk. Then we attach the filesystem to the mount point desired. When IRP requests come in, we will immediately split it into three; diskDevice to handle the fake disk related requests. ioctlDevice which handles the ioctls from userland, and finally fsDevice which gets the vnop requests from the mounted ZFS filesystem.

IRP_MJ_CREATE appears to serve the purpose of vnop_lookup, vnop_open and vnop_create. The "create" in this context is more in the line of "create a handle to file/dir" - existing, or creating, entries.

Directory listings come in the form of IRP_MJ_DIRECTORY_CONTROL + IRP_MN_QUERY_DIRECTORY. Unfortunately, it also has a "type" of struct wanted, one of nine. Although, it appears mostly three are used. Still that is somewhat frustrating.

Each return struct has an "offset to next node", relative to each node, and the final is zero to indicate last entry in buffer. Each struct is followed by filename in typical windows fashion, in 2byte chars. Due to variable length filename, the next struct start has to be aligned to 8 bytes.

As long as there are valid entries in the return buf, it needs to return STATUS_SUCCESS, annoyingly, even when EOF has been reached. So EOF has to be remembered until next call, at which time it returns STATUS_NO_MORE_FILES. The query directory can also pass along pattern to match against, which is only passed along in the first call, and needs to be remembered. Similarly the index (in OpenZFS terms, the directory offset) needs to be saved. These are stored in the "fscontext2" void* ptr assigned to the directory in MJ_CREATE. Often called "Ccb".

We will use "fscontext" for the znode ptr.

← Older revision		Revision as of 08:44, 18 May 2017
Line 1:		Line 1:

−	~~== Windows Port ==~~
−
−	~~Until it has its own space, I am using this space to jot down some of the findings.~~
−
−	All the IO Request Packets (IRP) all come in through the same set of function handlers, which can get a bit noisy. So ioctls from userland to, say, listing datasets, come in to the same place, as requests to list a directory, and volume creation notifications, etc etc. It gets a bit noisy.
−
−	To trigger a mount, we add two new ZFS ioctls, for mount and unmount. In mount we will create a new fake disk, then create a filesystem that we attach to the fake disk. Then we attach the filesystem to the mount point desired. When IRP requests come in, we will immediately split it into three; diskDevice to handle the fake disk related requests. ioctlDevice which handles the ioctls from userland, and finally fsDevice which gets the vnop requests from the mounted ZFS filesystem.
−
−
−	IRP_MJ_CREATE appears to serve the purpose of vnop_lookup, vnop_open, vnop_mkdir, and vnop_create. The "create" in this context is more in the line of "create a handle to file/dir" - existing, or creating, entries.
−
−	~~We will use "fscontext" for the vnode *vp pointer, which gets you znode_t pointer via VTOZ() macro.~~
−
−	Directory listings come in the form of IRP_MJ_DIRECTORY_CONTROL + IRP_MN_QUERY_DIRECTORY. Unfortunately, it also has a "type" of struct wanted, one of nine. Although, it appears mostly three are used. Still that is somewhat frustrating.
−
−	Each return struct has an "offset to next node", relative to each node, and the final is zero to indicate last entry in buffer. Each struct is followed by filename in typical windows fashion, in 2byte chars. Due to variable length filename, the next struct start has to be aligned to 8 bytes.
−
−	As long as there are valid entries in the return buf, it needs to return STATUS_SUCCESS, annoyingly, even when EOF has been reached. So EOF has to be remembered until next call, at which time it returns STATUS_NO_MORE_FILES. The query directory can also pass along pattern to match against, which is only passed along in the first call, and needs to be remembered. Similarly the index (in OpenZFS terms, the directory offset) needs to be saved. These are stored in the "fscontext2" void* ptr assigned to the directory in MJ_CREATE. Often called "Ccb".
−
−	~~directory-listings also can be passed a filename, either with wildcards or not, which you have to match against. This is only given in the first call, so that is stored in ccb.~~
−
−	Deleting files and directories are done a little differently. It calls IRP_MJ_CREATE to open a handle to the file or directory, then calls IRP_SET_INFORMATION with type FileDispositionInformation, which has a single entry "delete". Then it calls IRP_MJ_CLOSE, and eventually IRP_MJ_CLEANUP. And if this is the final reference to the file/directory, we call vnop_remove/vnop_rmdir. The "delete flag" is stored in the vnode, using the new vnode_setunlink() and vnode_unlink() calls.

@@ Line 9: / Line 9: @@
-IRP_MJ_CREATE appears to serve the purpose of vnop_lookup, vnop_open and vnop_create. The "create" in this context is more in the line of "create a handle to file/dir" - existing, or creating, entries.
+IRP_MJ_CREATE appears to serve the purpose of vnop_lookup, vnop_open, vnop_mkdir, and vnop_create. The "create" in this context is more in the line of "create a handle to file/dir" - existing, or creating, entries.
 Directory listings come in the form of IRP_MJ_DIRECTORY_CONTROL + IRP_MN_QUERY_DIRECTORY. Unfortunately, it also has a "type" of struct wanted, one of nine. Although, it appears mostly three are used. Still that is somewhat frustrating.
@@ Line 17: / Line 19: @@
 As long as there are valid entries in the return buf, it needs to return STATUS_SUCCESS, annoyingly, even when EOF has been reached. So EOF has to be remembered until next call, at which time it returns STATUS_NO_MORE_FILES. The query directory can also pass along pattern to match against, which is only passed along in the first call, and needs to be remembered. Similarly the index (in OpenZFS terms, the directory offset) needs to be saved. These are stored in the "fscontext2" void* ptr assigned to the directory in MJ_CREATE. Often called "Ccb".
-We will use "fscontext" for the znode ptr.
+directory-listings also can be passed a filename, either with wildcards or not, which you have to match against. This is only given in the first call, so that is stored in ccb.