|
|
 |
 |
 |
 |
 |
 |
|
|
|
From: Perry and Lorae Merritt (plmerritt, hypermall dot net) Date: 2002.01.06 - 17.06 MST
X-Mailer: Microsoft Outlook Express 6.00.2600.0000 I stand corrected. Jay is right, there is no fioctl, I was thinking of fcntl. So now the question is do we need to use fcntl or can we use ioctl? Doh.. you're right, there are four, not three components listed. I forgot to talk about the data store in this thing. I think I'll put it in the policy based management one and take it out of this one. I moved you to Boulder, you liar. If you can lie about where you live, I can lie about the purpose of the VFS. I changed it to read operating system rather than applications. Tautological?? If you were trying to impress me, it didn't work. I don't know what the word means. I fixed the spelling. As far as the other comment, the tautological one, I left it. I was trying to say that file systems really only need to supply the required VFS interfaces. If there's a better way of stating it, shoot it my way and I'll put it in. I was thinking that a CLI is different from a script in that only one command is called. Is that wrong? I said hereafter ALSO known as. Come on now. I took your suggestion. It reads better. I also added the "two". In your comment regarding (10) aren't we calling the functions pointed to in the file operations and inode operations tables? There aren't multiple inodes per file??? What happens when a single inode can't describe the whole file like in the case of a very fragmented file? I couldn't agree more with your comments on the Summary. I hated it when I wrote it. Actually, not all of the patents I looked at end this way, just the one we were awarded from STK. I don't have a problem removing it since it doesn't add anything technical to the patent. Thanks for your careful read. I didn't do it after I wrote it. I just typed the last words and put it in an email. I pretty much took all of your corrections (except where I had questions above, I left them the way they were until I hear back). Ill fix the drawing numbers after I get all of the feedback. I don't want to renumber everything more than once. Thanks again. P ----- Original Message ----- From: "Jay Miller" <jnmiller, cryptofreak dot org> To: <antera, enigma dot cryptofreak.org> Sent: Sunday, January 06, 2002 5:59 AM Subject: Re: First patent > 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 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 |
