2011/10/26 Yuping Luo <lypingsh@xxxxxxxxx>
> +void fsg_lun_fsync_deferred_func(struct work_struct *work)
> +{
> + struct fsg_lun *curlun =
> + container_of(work, struct fsg_lun, fsync_deferred_work);
> +
> + fsg_lun_fsync_sub(curlun);
> +}
> +
> static int do_prevent_allow(struct fsg_common *common)
> {
> struct fsg_lun *curlun = common->curlun;
> @@ -1510,7 +1518,7 @@ static int do_prevent_allow(struct fsg_common *common)
> }
>
> if (curlun->prevent_medium_removal && !prevent)
> - fsg_lun_fsync_sub(curlun);
> + schedule_work(&curlun->fsync_deferred_work);
Alan, i can't find enough information from usb mass storage spec about this.
does ALLOW_MEDIUM_REMOVAL need to sync fs? if no, the
fsg_lun_fsync_sub(curlun) actually is needless at all. let pdflush
thread write-back page cache on demand is the right way.
otherwise, our patch is wrong. if fsync must be done in the mass
storage spec, our patch changes the sync thing to async and will
destory some other part.
> curlun->prevent_medium_removal = prevent;
> return 0;
> }
Thanks
barry
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
