Hi Mayur -
You're right - that is pretty inconsistent. I think it's left over from one of the first implementations of Blackbook on TinyOS 1.x, and I forgot to update the interface's comments. There is a major design issue with allowing the event to give you back the filename, which is why it was removed. The issue is the filename is never stored anywhere in Blackbook except on non-volatile memory. The first thing Blackbook does when you pass in a filename is it converts the filename to a CRC and uses the CRC as a hash to refer to the filename. The actual filename itself is written directly to flash one time, and forgotten about until you absolutely want to know what it is. Having the ability to recall the filename from an event requires one of three things to happen: 1. Each operation that signals an event that supplies the filename must do a read from flash to determine what the filename was. This is not optimal because each flash interaction costs lots of time and energy. 2. Each operation that signals an event that supplies the filename must maintain the filename in RAM. This is not optimal for some applications that are limited on RAM. 3. The external application layer must supply Blackbook with a filename to open; therefore, the application layer knows what the filename should be at some point. By forcing the application layer of an application to store the filename in RAM, it prevents all applications that use Blackbook from paying a filename penalty when they don't need that functionality. Each particular instantiated interface into Blackbook should be able to handle only one open file at a time, so if you're dealing with multiple open files you'll also be dealing with multiple copies of interfaces into Blackbook. Therefore, at the time you call BFileWhatever.open(.) you could also store the filename into your own application's "openFileName" buffer for that particular interface. Btw, BlackbookUtil.filenameCpy(..) is an easy method to copy a char * filename into a given filename_t buffer. Hope that explains some details. I need to go fix those comments, thanks for pointing them out. -David _____ From: Mayur Maheshwari [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 1:50 PM To: tinyos-help@millennium.berkeley.edu; David Moss Cc: Suvesh Malhotra Subject: BlackBook File System, BFileWrite interface Hi David I had a chance to test the BBFS on my telosb mote running TOS2 and I ran a small app to use BFileWrite and BFileRead interfaces and they worked as expected. However, while bulding up an advanced application I required to know the name of the file whenever I opened one (with BFileWrite or BFileRead) and I found that the comments and the actual implementation are inconsistent. For eg. in the interface BFileWrite http://tinyos.cvs.sourceforge.net/tinyos/tinyos-2.x-contrib/rincon/tos/lib/b lackbook/interfaces/BFileWrite.nc?view=markup starting line 94: / * Signaled when a file has been opened, with the errors * @param fileName - the name of the opened write file * @param len - The total reserved length of the file * @param error - SUCCSES if the file was opened successfully */ event void opened(uint32_t len, error_t error); The parameter fileName is absent from the event implementation. For cross-checking I saw the BFileWriteP.nc in \opt\tinyos-2.x-contrib\rincon\tos\lib\blackbook\core and found that the fileName is not present in the actual implementation too. The same situation is present with the events like appended, saved, closed. Is it possible to include the fileName parameter when these events signal. This would enable us to handle multiple opened files.egards Regards -- Mayur Maheshwari([EMAIL PROTECTED]) "Karmanye Vadhikaraste Ma Phaleshu Kadachana, Ma Karma Phala Hetur Bhurmatey Sangostva Akarmani"
_______________________________________________ Tinyos-help mailing list Tinyos-help@Millennium.Berkeley.EDU https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
