Hi, i might get a community problem with the goal of my patch. While googling for hints of acceptance for cdrom on linux-scsi@xxxxxxxxxxxxxxx i came to a thread where a much more expensive fix of the problem was obviously rejected by Jens Axboe in november 2019: https://lore.kernel.org/linux-scsi/c6fe572c-530e-93eb-d62a-cb2f89c7b4ec@xxxxxxxxx/ "I think the main complaint with this is that it's kind of a stretch to add core functionality for a device type that's barely being manufactured anymore and is mostly used in a virtualized fashion. I think it you could fix this without 10 patches of churn and without adding a new ->open() addition to fops, then people would be a lot more receptive to the idea of improving cdrom auto-close." Well, 10 patches. Each about the code size of my single one. But also a negative opinion towards the device class by the maintainer. That proposal fixes tray loading for audio, too. I did not care because i cannot test realistically. Then there are patches 04/10 and 08/10 which shall avoid blocking other processes from inquiring the drive while it is loading its tray because of the automatic load feature in open_for_data(). Mine has a 40 seconds timeout instead, blocking CDROM ioctls and sr_bdops.open() == sr_block_open() to that particular drive. Would it be wise to mention from the beginning that i studied that proposal ? My opinion is now that if concurrent access from multiple threads to a drive is more important than a working automatic tray load on open(2), then automatic tray loading should be disabled at all. If concurrent drive inspection by multiple threads at any time is not a main goal, then i would still advertise my patch. Should i mention this opinion from the beginning ? I have a few other cdrom+sr fixes in my local 4.19 kernel. I don't want to spoil their chances by starting with a non-starter. Any strategic proposals to not appear clueless in front of Jens Axboe would be welcome. Due to real life issues i will probably until mid of next week not be able to post a patch on linux-scsi and to then react swiftly on demanding requests. ----------------------------------------------------------------------- Lukas Bulwahn wrote: > Archives at https://lore.kernel.org/ can give you the raw text and that > archive is tested among kernel maintainers for picking patches. > You can prepare your patch and send it to kernelnewbies. > Then, pick it from https://lore.kernel.org/kernelnewbies/ and try to apply > your own patch with git am. If that works, it is probably fine. Pawan Gupta wrote: > $ ./scripts/checkpatch.pl --strict --codespell -g <commit-id> > $ make CFLAGS_KERNEL+=-Werror ... I surely learn a lot here. Already lagging behind now ... :) Have a nice day :) Thomas _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
