> > I think it would be quite a lot of work but worthwhile > > 1, add emulation of writing to a dvd to cdemu. This is not that very > > hard, at least if you only aim to support to burning to single-session > > dvds. > > 2, should probably work with the cdemu people and break > > cdemud-device.c out into a separate link library that tgtd could link > > to. > > (maybe keep mmc.c still around as a last resort and use it if > > cdemud-device.a is not available?) > > 3, rework the public api in cdemud-device.c to remove exposing the > > glib/dbus dependencies and make the exposed api only use posix types. > > (I think one very attractive feature of the tgtd codebase is that it > > has so few dependencies on headers from other packages) > > > > > > 1 is only important if we want to keep the "tgtd can burn to emulated > > blank disks" feature. > > 2 would open up code sharing and reuse between cdemu and tgtd, and > > other projects that want to access a scsi mmc emulation library. > > 3 is only my personal view. I really like that tgtd does not depend on > > glib or other external packages. > > Yeah, agreed. cdemu is released under GPL. I prefer just exploiting > (or stealing) their code. > > I have no time to work on multi-session support but patches are very > welcome. 3 sounds like a perfect trade-off. As an additional module, like 'mmc', it would allow for enhanced 'read-only' functionality, 'light' integration, and additional functionality. It may also facilitate a cleaner integration with simplified up-merges. Matthias -- To unsubscribe from this list: send the line "unsubscribe stgt" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
