OSDev.org

Okay, I took a day off and helped my little sister move so I missed all those wonderful posts until just now.

to Jal:

I think that a full search using a SQL like database would be possible even with different data types, I plan for my OS to understand how to read the different datatypes. obviously you wouldn't search a PNG or JPG for a text string, but you could search an html, txt, doc, rtf, docx, ... etc. All you have to do is know how to read them and I want any program that has a new file compatability to modify a part of my OS so that my whole OS knows how to read the file. Really all photoshop or office do is translate a specific file type that they want to use, I want the code that does the translation to be integrated and classified as either text or graphics. text would be search able and graphics would not. more complex file types like a database file might require a little extra work or might simple be determined to be unsearchable. That is to be figured out at a later date.

As for the FAT Files Systems. I am going to use FAT12, which I already have for my bootloader, to lessen the time required for getting my RAMDisk running. I don't plan to stick with FAT12 and I also don't plan to stick with my initial RAMDisk implementation. I am simply using it as a tool to move to the next step. When I get a better design of what my API should look like I will change the RAMDisk to be properly implemented. when it is all said and done my RAMDisk will probablly have a custom Kernel FS that is incompatible with all other FS's and will be extened using internal commands.

To Love4Boobies:

I know that WinFS is a Subsytem that runs ontop of the FS. I had forgotten that is was only using Metadata, but that is not really important as I was only after the enduser functions and not really the implementation. I would like to have a way, other than just putting them in the same folder, to have files linked in the manner you stated. I want an email about a meeting to give you a link to add a calendar event and a way to associate documents created for or during the meeting with that meeting. I would also like to allow, in myspace terms - horrible website by the way, a user to "tag" a document or photo so that your photos and such could be sorted by who is in them, why they were taken or any other user decided criteria with out having to clump them in folders and decide to sort them this way or that for all eternity.

To Bewing:

While you have described what I would consider the proper way of doing things. For right now, this is a bastardized RAMDisk implementation just to get some dirty stuff out of the way and I will polish the poo after I have more things worked out. I don't find it very easy to write things down and work them out. I am much better at slapping some code in there and seeing if it works. I plan on going back and optimizing or redesigning all of my code after I figure out how parts work. Actually after I get a simple shell with enough functionality to run a program that is external to my kernel, in the RAMDisk is fine, then I will go and fix any code that I can and maybe reinvision somethings.

I would like to thank everyone for the help and links to different resources.

Usually that programming style works for me, too -- but not in this case. If you want to use Brendan's method, where data block caching is done at the VFS level, and the "ramdisk" is a modified usage of the data block cache -- then you need to be thinking about how to build a generic VFS data block cache for all block devices. About how to uniquely map "logical clusters/inodes" on each device to a chunk of preallocated memory, how to force some cached blocks to never swap out, and how you plan on handling directory entry creation/modification (because directories are handled specially by a VFS, usually).

If you want to make a ramdisk driver (like mine) then you need to be thinking about how to map LBAs into a memory structure. (And how to force the block cache to NOT cache ramdisk blocks, later.)

It sounds like you are interested in creating a ramdisk specific FS, though. But that presents some different problems. What will be the inputs from the VFS layer? Filenames, offsets, and directory entries? You don't have LBAs to work with. That is the main problem -- deciding what your inputs will be.

Yeah, I am not sure how I am going to handle all that. My intent right now is to just any ol RAMDisk up and running and then modify it to meet my needs. I also don't plan on having folders. As I mentioned but may not have elaborated on I would like to use a flat FS with folders not really being folders but more groups. any file could belong to any number of groups.I will try to show in ASCII:

FS Table: Tag Table
+-----------------------+ +----------------------------+
| ID | Name | DATA | | ID | FileID | Name |
|----|--------|--------| |----|---------------------|
| 0 | foo | #$% | | 0 | 0 | badfiles |
+-----------------------+ +--------------------------+

and so on.

then in the "Directory" or rather group structure you would have a "folder" called badfiles and inside that you would have the file foo. I suppose that any file belonging to a group would not show in the root but files not having a group would show.

Now that is for the User file system, the Kernel file system which would be my first RAMDisk would be a completely flat FS with no folders. I don't see how I would need them since the only thing in that directory would be kernel drivers. and possibly a disposable registry type construct.