Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I am currently trying to port new lib and i found most of the system calls are file IO, my current floppy / FAT driver is to unstable, so i've decided to make a system for making and read/writing ram disks, i would like file hierarchy to be similar to most UNIX systems ( /usr/src, etc.. ), i have written this:
It depends what format you want to use. I have one ramdisk, the initrd, which loads as a GRUB module. It is in a propriatery (sp) format that is just basically a load of headers then data. Headers give offset of data start and length etc. Subdirectories are not supported.
int read(int off, int l, char *buf)
{
Header *curHeader = <get header for cur file>
<do error checking on offset-length>
memcpy(buf, header->data_start+off, l);
return l;
}
int write(int off, int l, char *buf)
{
return EROFS;
}
So, you can't write to it This takes a lot of the complexity out of the ramdisk driver, and considering I only need it so I can load my other drivers, I never need to write anyway!
well, I'm going to most likely to mount my ramdisk as root ( / ), so there will be a lot of reading and writing, i was kinda thinking it could somehow be done as a linked-list tree:
GLneo wrote:how to access the FS helps, but i still don't have down how things will be organized on the disk...
I would organize it the same way it is on a floppy disk. It would start with a boot sector and then be followed up by more sectors, it wouldn't be forced to be 1.44mb though. Or you could think of it as a partition.
Hmm... it seems you think I'm making a virtual floppy disk, why would i need a boot sector on a ram disk?
I've been doing some thinking, I might save memory space by not allocating the whole disk, just malloc for new files:
ramdisk_make( int size ), would just set the max size of the disk and as more disk space is needed memory is added via a linked-list style thing.
also why would i want to use FAT, that seems meant for real disk's, a memory disk should be easier to access( just store file location's in variables, ( not in a table )), this also would prevent fragmentation that occurs with physical disks.
GLneo wrote:I've been doing some thinking, I might save memory space by not allocating the whole disk, just malloc for new files:
ramdisk_make( int size ), would just set the max size of the disk and as more disk space is needed memory is added via a linked-list style thing.
also why would i want to use FAT, that seems meant for real disk's, a memory disk should be easier to access( just store file location's in variables, ( not in a table )), this also would prevent fragmentation that occurs with physical disks.
what do you think?
That would work just fine.
In my kernel all disk drives are derived from CDrive so that all I have to do is pass a pointer to a CDrive to my file system driver and it can call read though that pointer. Each individual driver is responsible for detecting whether it can use this drive(actually I pass a pointer to a CPartition class) or not. If I were to implement a ram disk I would just derive a CRamdisk class and then pass that to the file system driver. That way you can use any supported file system on the ram disk and there is no special casing in order to support it.