Hi Matt, Thanks for the extra information. As for Minix implementation, and because of the very meaning of inode and the notion of file descriptor, I keep traces of where I currently am within a file, being the block address, the byte number within that block, the number of bytes being read, etc... So there's no need to re-read fragment (ie. block or zone in Minix) from the beginning. At a cost, obviously: size of an inode + extra state information. I guess this is a reason why my lib is growing much bigger.
I'll try to stick to Minix specs, and, since it's also an educational project, try to implement as much as I can. Then I'll cut in it to extract something more suitable to MCU (if required, who knows, I may find a incredible way to reduce resource usage :)) Cheers, Seb 2011/5/6 mattschinkel <[email protected]> > You could also think about how copying files would work. If you don't > store fragments your copying will be quite slow when you get to the > end of the file since your lib will need to start reading fragments > from the beginning. > > With my method, I should be able to easily implement ability to have > more then one file open at a time. Of course this would require yet > another 512 byte buffer + somewhere to store fragments of the 2nd > file. Again, I can store this info in an external memory. > > Matt. > > -- > You received this message because you are subscribed to the Google Groups > "jallib" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/jallib?hl=en. > > -- Sébastien Lelong http://www.sirloon.net http://sirbot.org -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
