michallenc commented on PR #16642: URL: https://github.com/apache/nuttx/pull/16642#issuecomment-3046288326
> @michallenc is out expert in this area so I follow all his remarks :-) I wouldn't mark myself as an expert in this area, but still thanks :) > What happens if we use SYNC flag assuming the memory is erased but it is not erased? Is this scenario handled properly with returning error code? I think this would be pretty hard to achieve. The behavior will be flash specific. If NOR flash is used, then the result would be incorrectly written bits (erased state bits will be changed to write state bits correctly, usually ones to zeros, but not vice versa - you can't write logical one if already written to zero before). To check this with error code would mean the driver would have to read what was written and perform `memcmp` to what user wanted. Even Linux doesn't do this automatically afaik. The point of SYNC flag here is to skip this logic in the driver and let the application handle it if it wants/must to. > Should we mark this change with [BREAKING] tag in the commit topic too? It changes filesystem / mount / mtd in a non-backward compatible way and this should be clearly marked if someone bumps the release and gets a broken code it will help find a fix quickly. Maybe it would be possible to create new function calls with additional flags as new functionality while old API remains untouched (could call new functions with default parameters)? What other folks think? :-) Good point, maybe safer to mark it as breaking. Change in `bchdev_register` will be backwards compatible after the fix, but `ftl_initialize_by_path` is still breaking (although it breaks in compile time, so the user is notified immediately, that's the better option). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
