It looks like mmc code will be expanding a bit. Furthermore, I think we want to turn this into a library. From my standpoint, a library inside libcdio is the easiest. But even if it is moved out, making it a library inside libcdio is a useful and easier step.
Still it is more involved than I want to directly undertake right now. So first some smaller changes. A little background about things in lib/driver. Files that are related and form a unit I have been putting in its own directory. For example the various image drivers (BIN/CUE, TOC, Nero) located in lib/driver/image. So mmc-related things are now in lib/driver/mmc. The individual files in that directory start mmc_, but of course when this becomes its own library then I can drop the mmc_ prefix which I hope to do. Previously there was just one source code file here mmc.c. However it looks like we want to layer the code at least 3 files. One file contains low-level stuff like things that turn enumerations/indices into strings, like mmc_sense_key2str[] or Frank's mmc_is_... routines. That currently remains in mmc.c, but under directory mmc.c now. If this were a library I might call it core.c or something like that. There is code in mmc.c that should probably be moved to one of the other files, but I haven't gotten around to it. A second file contains the largely 1-1 SCSI-MMC commands. That is now called mmc/mmc_ll_cmds.c for "low-level commands". Please note that I've spend some effort to reduce the boilerplate code that appears everywhere in issuing MMC commands. In some of the original tests that Thomas wrote, he duplicated cod to issue MMC commands that already was in mmc.c. In other cases where the MMC command needed in a test didn't previously exist, I have now created them. In particular mmc_mode_select() and mmc_test_unit_ready(). A third file contains the higher-level MMC functions mmc/mmc_hl_cmds.c (hl for "higher level"). The thought is that they would largely call the lower-level routines to get things done. Important is the fact that you shouldn't have to issue an MMC command directly. So consider Frank's mmc_get_disctype() routine. It issues a MMC GET CONFIGURATION command, customized for its particular needs and then it parses the profiles returned. Probably the profile parsing part is something that will be used over and over in different situations so that aspect of it would probably be a function in what is now called mmc.c. But rather than issue a MMC GET CONFIGURATION in mmc_get_disctype by declaring and initializing a CDB variable, I added the more generic GET CONFIGURATION routine in mmc_ll_cmds.c. It is called mmc_get_configuration(). I am not thrilled about the choice of file names mmc.c, mmc_ll_cmds.c and mmc_hl_cmds.c. It is likely that these file names when we come up with better ones.
