|
|
 |
 |
 |
 |
 |
 |
|
|
|
From: Jay Miller (jnmiller, cryptofreak dot org) Date: 2002.01.06 - 05.59 MST
X-Mailer: Mutt 1.2.5i First of all: nice work, Perry! I was pretty impressed reading over all you've cooked up here - it's very pro. I still have lots of little comments to pass on, tho! - Words by Perry Merritt <Perry_Lorae, merrittclan dot com> [020105 13:19]: > Ok, I finally got the first one ready for review.There is one known problem (there is no number 22, I go from 21 to 23) and I have questions about #23 and #25. For #23 I say ioctl, is it really going to be an fioctl or does it matter? For #25 I did my best to insert a queue, but I'm not sure its needed. Is each call we get going to be part of a unique kernel thread? If so, I think we can block the thread and eliminate the need for a queue. Hmm. Whether or not you specify 'ioctl' or 'fioctl' seems somewhat unimportant to me. We're not making any claims on how a transport mechanism might work, after all. It seems like we might just say something like, 'any of the standard kernel mode to user mode data transfer mechanisms'. Oh, and I don't even know what an 'fioctl' is. As for the question of a queue, I'm not sure we need this. My feeling is that, in keeping with our original premise of simplicity in the kernel code, any queueing should take place in the portal. Besides simplicity, if there is a queue, it shouldn't matter if it's in kernel space or user space, right? My current implementation doesn't include a queue, and I don't *think* it's really necessary. Any operation that requires this filter-portal transaction is going to have to wait for the portal anyway, right? Isn't that the whole point? ..that we can't just let the request pass through without first acting on it ourselves? otoh, I do have the blocking ioctl (the 'read' ioctl, from the portal's perspective) reopening immediately. It is able to do this because once it reads from the ioctl, it immediately spawns a (user mode) thread to handle the read ioctl arguments and (when it's finished) return status. This status return (via the second standard ioctl) is what brings the original process off the kernel wait queue to finish the request by calling the true FSD function, whatever it is. So a process sleeps when it talks to the portal, but many processes can be brought to such a state concurrently. (via the portal's own threads) Does that help any? > I'd appreciate your comments on this. Okay. You asked for it. Here's some comments. Warning: I am both tired and dumb, so don't take them too seriously. *** > Abstract > The system provides a mechanism necessary to intercept file activity > without interfering with normal data flow. The system is comprised of > three major components, a file system filter, a transport, a policy > store and data management applications. The system monitors file control By 'three major components', I'm not sure what you mean: it looks like you have four listed, or maybe you missed an 'and' in there somewhere? > Inventors > Perry Merritt (Broomfield, CO), Jay Miller (Superior, CO), Is there any way I can be from Boulder too, or is it bad to lie? > PROBLEM > Storage products are typically designed with limited to function within /with limited/d > Other issues such as replication to remote facilities, virus scanning, > encryption are typically solved in a similar fashion, that is an Would an 'or' or an 'and' be appropriate in there? > DETAILED DESCRIPTION ... > (1), or VFS. The VFS provides a standard interface to applications that I'm not sure this is technically correct. I think applications have had a standard interface to file systems, even before the VFS idea. That's the 'system call' abstraction. The VFS is intended to help out the *kernel* in supporting multiple file systems, I think. Sound right? > to the applications using it. File systems (3) are only required to > conform to the VFS interface published for files systems use. For one, you spelled 'file system' wrong in this sentence. But also, I don't really understand the point here: it sounds kinda tautological.. 'file systems are required to conform to the rules for file systems..' ? > In this system a file system filter (2), hereafter also known as filter, > has been inserted between the files system and the VFS. The filter /files system/file system/s > applications (6) & (8) through mechanisms such as command line > interfaces, sockets and scripts. I'm not sure a CLI is sufficiently different from a script. After all, don't scripts just use CLIs? Maybe something like a C API? 'program interface'? <shrug> > The file system filter may be inserted into the system any time after You said about that 'file system filter' will hereafter be referred to as 'filter' so: /file system filter/filter/s. > inserting the filter involves creating a set of function pointers (9) to > link the filter to the VFS and the file system. The two sets of pointers > are described as "in" and "out". The "in" function pointers replace the First you say 'a set', then you say 'two sets'. I suggest you say 'two sets' for the first reference, then just use 'they' for the second. And instead of 'described' you might want to say 'referred to' or something. <shrug, again> > functions file system functions normally called by the VFS and the "out" Take out the first 'functions'. > functions (10) in the filter driver as if it were calling the file > system pointers and the filter will either provide additional processing We don't call pointers, I don't think - we call functions..? > before passing the request to the file system functions or immediately > call the files system functions, essentially passing the VFS request Again, /files system/file system/s. > file (15), the VFS call a function to read the first inode (16), or /call/calls/s. Also, get rid of 'first' - there aren't multiple inodes per file. > Figure 4 describes the general process of filtering file system activity > and providing additional data management processing as part of the > normal data path. Each time a a filter function is called (20) from the /a a/a/s > filter includes tow types of interfaces to the application space. These /tow/two/s > interfaces are functions know as ioctl, or IO control, functions. The Usually the preferred alternate is listed second.. so, 'IO control, or ioctl, ...' <shrug> > ioctl. The transport will spawn a new process of thread to handle this /of/or/s > interfacing will include sockets, RPC, and scripts. When the application > has completed the required action status is either obtained directly Again, are scripts too high-level? Also, you need a comma in that second sentence: I think after 'required action'. > Summary > The system to capture file activity for the purpose of providing > intelligent data management to a storage system serves to allow storage > systems to use data management applications as part of the base > functionality they provide. Um, I'm not sure I like this. I suspect all patents end in this way, but, ah, it's kinda clunky. First, it seems like they are meant to take the form, 'The system xxxxx serves to yyyyy', where 'xxxxx' is a description of the system and 'yyyyy' is how the system *helps*. So, since the title of the thing seems good for the 'xxxxx' part, I think you should remove the 'to a storage system'. As for the 'yyyyy' part, um, I dunno. I like the 'base functionality' bit..? <shrug> Okay, that's it from the typo-police! Again, Perry, great stuff!! > I'm also including the other two patents I didn't read these yet - MUCH too tired to even go to my printer right now. -- Jay Miller -- This is the antera mailing list. To unsubscribe, email majordomo, cryptofreak dot org with message body `unsubscribe antera'. Or, for more information, visit http://www.cryptofreak.org/.
This archive was generated by hypermail 2b30 : 2002.01.07 - 04.02 MST |
