Please give advise about my first patch attempt

[Thomas Schmitt]

Hi,

i might get a community problem with the goal of my patch.

While googling for hints of acceptance for cdrom on
linux-scsi at vger.kernel.org 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@kernel.dk/
  "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