Not clear where you made these changes. Are you referring to the sample app function test_file_write()? Not sure what is going on. Assuming the file system got corrupted, you can try recreating it. We

That is correct.

This is the sector size. Data transfer size of the physical storage media. Minimum size of storage the file system will allocate when writing new data. Will be multiples of block size. f_frsize is all

The file system will work provided a disk access layer and flash driver is implemented for it. Currently these are only implemented for Winbond flash on the Arduino 101 boards. (susbs/disk/disk_access

Looks like this only serves as a debug of init failures. We can instead use ASSERT for that purpose. In my opinion, if there is no other valid use case for this, we should remove the check and move th

Yes, I agree that we will most likely have only one file system. I am looking into making the glue layer as thin as possible. Some functions have different parameters, while almost all of them need to

The primary goal is to provide a file system without impacting the small footprint requirements of the OS. Using some existing interface would force the design to be fully compliant with that interfac

Thanks for all the feedbacks. The APIs, after updating with feedbacks from the mailing list and gerrit, are listed below. Will track and submit updates if any comments were not addressed correctly. Cu

I would like to simplify this and always move the pointer relative to beginning of file. The other options can be easily accomplished by ftell() + offset and fsize() + offset, if necessary. /** * @bri

No, they have not been discussed. Thanks for your feedbacks. I totally agree with you. Following are couple of options. 1. int fs_open(ZFILE *zfp, const char *file_name); - Opens file if exists - Crea

We don't have a non-re-entrant version so we don't need to differentiate the way stdio needs to. Also we are not strictly following stdio signature. These functions can be useful and we can add them.

A file system is necessary to store data reliably and to be accessed in a consistent and deterministic manner. Example applications are data logging, media files and file based databases which would n

Is there a specific requirement for the revision id? Is SOC ID enough to meet the requirement?

The device PM states look ok to me. They are architecture independent and the drivers can map them to device specific operations. I think this RFC should be part of other RFCs that define the bigger p

That does not explain why 2 functions are better than 1. In the scenario you mention, all that is needed is a way to notify the device of a power state transition.

That made me think why we originally came up with 2 functions when one was enough. Probably we thought the same way - to keep symmetry. Problem is that we will keep getting more needs and we will eith

Currently suspend and resume are not actually states but a notification of the state transition. There is a second argument to those functions that specify the current policy for which the transition

I assume you are referring to Deep Sleep. In that case the system will resume from the reset vector after a reset. However, if the state is saved correctly, it would seamlessly resume from the point i

As of now, PM in ARC can be done using IPM (inter processor messaging) from the x86 side. You can refer to samples/ipm to see how x86 and ARC can communicate. When x86 side gets notified via _sys_soc_

One useful feature would be a link to a pre-generated html or pdf so the reviewer need not generate them - especially when one is reviewing associated code.