From: "Thomas Schmitt" <scdbackup@gmx.net>
To: kernelnewbies@kernelnewbies.org
Cc: lukas.bulwahn@gmail.com, garritfranke@gmail.com, greg@kroah.com
Subject: Re: Please give advise about my first patch attempt
Date: Fri, 28 Aug 2020 15:03:26 +0200 [thread overview]
Message-ID: <8257736897954643869@scdbackup.webframe.org> (raw)
In-Reply-To: <alpine.DEB.2.21.2008271905160.16067@felia>
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/
"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
next prev parent reply other threads:[~2020-08-28 13:03 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-27 8:49 Please give advise about my first patch attempt Thomas Schmitt
2020-08-27 9:26 ` Lukas Bulwahn
2020-08-27 16:34 ` Thomas Schmitt
2020-08-27 17:30 ` Lukas Bulwahn
2020-08-28 13:03 ` Thomas Schmitt [this message]
2020-09-03 15:59 ` Thomas Schmitt
2020-08-27 9:52 ` Garrit Franke
2020-08-27 13:19 ` Greg KH
2020-08-27 14:02 ` Leam Hall
2020-08-27 16:01 ` Greg KH
2020-08-27 18:32 ` Pawan Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8257736897954643869@scdbackup.webframe.org \
--to=scdbackup@gmx.net \
--cc=garritfranke@gmail.com \
--cc=greg@kroah.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=lukas.bulwahn@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).