Re: Please give advise about my first patch attempt

Hi,

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

While googling for hints of acceptance for cdrom on
linux-scsi@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/ (local)
  "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@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies