On 08/20/13 10:21, Kevin Wolf wrote: > Am 16.08.2013 um 16:15 hat Laszlo Ersek geschrieben: >> Paolo asked me to write such a driver based on his textual specification >> alone. The first patch captures his email in full, the rest re-quotes >> parts that are being implemented. >> >> The tree compiles at each patch. The series passes "make check-block". >> >> "block/raw.c" is not removed because I wanted to keep it out of my >> series and out of my brain. >> >> Disclaimer: I couldn't care less if the raw block driver was public >> domain or AGPLv3+, as long as it qualifies as free software. I'm only >> trying to do what Paolo asked of me. >> >> Laszlo Ersek (7): >> add skeleton for BSD licensed "raw" BlockDriver >> raw_bsd: emit debug events in bdrv_co_readv() and bdrv_co_writev() >> raw_bsd: add raw_create() >> raw_bsd: introduce "special members" >> raw_bsd: add raw_create_options >> raw_bsd: register bdrv_raw >> switch raw block driver from "raw.o" to "raw_bsd.o" >> >> block/Makefile.objs | 2 +- >> block/raw_bsd.c | 186 >> +++++++++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 187 insertions(+), 1 deletions(-) >> create mode 100644 block/raw_bsd.c > > Reviewed if the individual added functions make sense, whether all > necessary function from struct BlockDriver are implemented, and which > fields from BlockDriverState need special handling (it's only bs->sg, > and we should probably get rid of that requirement) > > Looks good in general, but please CC Stefan and me for v2 (like for all > block patches).
Thanks for the review. Regarding your comments for 4/7: can we postpone the bdrv_is_sg() change to another series? Because, I can't just rebase / update this series as a "normal" series -- v2 will still be a "clean room reimplementation", and I must keep full history (basically, a documentation of the "clean room process") in the commit log. So, Paolo's suggestion for 7/7 (ie. raw_reopen_prepare() should just return 0) will be a separate 8/8, with his email quoted as commit message. (Normally I would just squash the change and add a short v2 note *outside* the commit log, but that's exactly what we can't do here.) ... Maybe I can still squash the change into 7/7, and extend only the commit message with Paolo's email, since that includes the wrong v1 code too. Anyway, under this MO, I have trouble implementing what you want, if only from the "how to structure the series" aspect. I think we shouldn't mix in any changes that are unrelated to the BSDL reimplementation *purpose* (as opposed to, related to the code). Once the series is applied, in a minimal, barely working form, under the BSDL, y'all who actually have a clue about the block layer can very quickly improve it. Does that sound acceptable? Thanks! Laszlo