MAME SVN History

199869 Revisions

r189228 Monday 19th September, 2022 at 06:33:50 UTC by Nathan Woods
Changed fs::manager_t::enumerate_f() to simplify logic within file system drivers (#10106) * Changed fs::manager_t::enumerate_f() to simplify logic within file system drivers enumerate_f() used to contain quite a bit of boilerplate logic to determine whether a particular floppy type should be added. This change attempts to move this logic outside the file system drivers to simplify the drivers. The riskiest part of this change is unformatted_image::enumerate_f(). I attempted to replicate the logic that was previously determining with unformatted image types to use, but the logic is tricky and it isn't clear to me that replicating the logic is the correct action - I may be cargo culting. * Fix to floppy_image_device::fs_enum::add_raw() * Updating FS_FAT to reflect this PR * On the advise of Sarayan, I moved the filtering to the fs::manager_t::fs_enum base class. This is actually a less intrusive change than what I originally had because it keeps the unformatted raw image handling closer to what we had previously. Some misgivings about these changes: 1. We now have fs::manager_t::fs_enum::add() being a thin call that invokes a protected method called fs::manager_t::fs_enum::add_format(). Better ideas for names are welcome. 2. It feels odd that we've removed the need to do filtering from the various FS modules, but the unformatted module has to ask the fs_enum() for its internal variables for filtering to perform the same logic. This seems to be the least worst option Feedback is welcome

r189228 Monday 19th September, 2022 at 06:33:50 UTC by Nathan Woods

Changed fs::manager_t::enumerate_f() to simplify logic within file system drivers (#10106)

* Changed fs::manager_t::enumerate_f() to simplify logic within file system drivers

enumerate_f() used to contain quite a bit of boilerplate logic to determine whether a particular floppy type should be added. This change attempts to move this logic outside the file system drivers to simplify the drivers.

The riskiest part of this change is unformatted_image::enumerate_f(). I attempted to replicate the logic that was previously determining with unformatted image types to use, but the logic is tricky and it isn't clear to me that replicating the logic is the correct action - I may be cargo culting.

* Fix to floppy_image_device::fs_enum::add_raw()

* Updating FS_FAT to reflect this PR

* On the advise of Sarayan, I moved the filtering to the fs::manager_t::fs_enum base class. This is actually a less intrusive change than what I originally had because it keeps the unformatted raw image handling closer to what we had previously.

Some misgivings about these changes:
1. We now have fs::manager_t::fs_enum::add() being a thin call that invokes a protected method called fs::manager_t::fs_enum::add_format(). Better ideas for names are welcome.
2. It feels odd that we've removed the need to do filtering from the various FS modules, but the unformatted module has to ask the fs_enum() for its internal variables for filtering to perform the same logic. This seems to be the least worst option

Feedback is welcome

[/branches/barcrest/src/devices/imagedev]	floppy.cpp floppy.h
[/branches/barcrest/src/lib/formats]	fs_cbmdos.cpp fs_cbmdos.h fs_coco_os9.cpp fs_coco_os9.h fs_coco_rsdos.cpp fs_coco_rsdos.h fs_fat.cpp fs_fat.h fs_oric_jasmin.cpp fs_oric_jasmin.h fs_prodos.cpp fs_prodos.h fs_unformatted.cpp fs_unformatted.h fs_vtech.cpp fs_vtech.h fsmgr.cpp fsmgr.h
[/branches/barcrest/src/tools]	image_handler.cpp

https://github.com/mamedev/mame/commit/5499683a239d9328a7c54b08135f31e7903ec772

199869 Revisions