On Sat, Jan 30, 2010 at 12:34 PM, Thomas Schmitt <[email protected]> wrote: ...
> Did i miss a new proposal of Frank ? > See the last paragraph of the original top post. > > ... > My team mate Mario Danic told me that he is > working on a MMC library. We sketched roughly > that it could replace one half of our current > MMC/SPC/SBC code and would swallow our system > adapters. > The other half of the current MMC code would > become part of the burn_drive methods. > > Maybe you can share thoughts with him about > the protoypes of a comprehensive MMC interface. > I think a mmc library is needed and that's why I started mmc.c over 6 years ago. It is bundled into the libcdio library, because it is not all that extensive (in fact in some ways it is still lame) and because of the affinity to OS drivers. It is conceivable that if there were a separate mmc library with drivers for each OS (or in some cases more than one driver per OS), then libcdio could use this library as a "mmc" driver much in the same way libburnia uses libcdio as a possible backend. > It should be more convenient than raw > mmc_run_cmd() See for example the 3 mmc_mode_sense commands. and keep the caller from doing > obviously inappropriate things. > That is for example why mmc_get_cmd_len() was created. On the other hand its doings should still be > recognizable in MMC specs. > No abstractions. > I'm not sure I agree with the no abstractions part. I suppose it depends on what one calls an abstraction. Is mmc_get_cmd_len() an abstraction? Is mmc_mode_sense() which may select either the 6-byte or the 10-byte version depending on which works an abstraction? But since this imagined mmc library is currently vaporware, I don't it worth discussing -- in the abstract ;-) If you start a common effort then i would be > your first user. :)) > Or rather libburn and libcdio would. > > > Have a nice day :) > > Thomas > > > >
