On Tue, Jul 08, 2025 at 09:32:19AM -0600, Jens Axboe wrote:
> On 7/8/25 5:35 AM, Andy Shevchenko wrote:
> > On Wed, Jul 02, 2025 at 05:13:45PM -0600, Jens Axboe wrote:
> >> On 7/2/25 5:08 PM, Ben Hutchings wrote:
> >>> On Sun, 2025-06-29 at 12:26 +0200, Uwe Kleine-K?nig wrote:
> >>>> On Sun, Jun 29, 2025 at 11:46:00AM +0200, Roland Sommer wrote:
> >>>>
> >>>> Huh, how did I manage that (rhetorical question)? Thanks
> >>>>
> >>>>>> Ahh, now that makes sense. pktsetup calls `/sbin/modprobe pktcdvd`
> >>>>>> explicitly, the blacklist entry doesn't help for that. Without the
> >>>>>> kernel module renamed, does the 2nd DVD-RAM result in the blocking
> >>>>>> behaviour?
> >>>>>
> >>>>> Yes.
> >>>>
> >>>> OK, that makes sense. So udev does in this order:
> >>>>
> >>>> - auto-load the module (which is suppressed with the backlist entry)
> >>>> - call blkid (which blocks if the module is loaded)
> >>>> - call pktsetup (which loads the module even in presence of the
> >>>> blacklist entry).
> >>> [...]
> >>>
> >>> I tested with a CD-RW, and the behaviour was slightly different:
> >>>
> >>> - Nothing automtically created a pktcdvd device, so blkid initially
> >>> worked with a CD-RW inserted and the pktcdvd modules loaded.
> >>> - After running pktsetup to create the block device /dev/pktcdvd/0,
> >>> blkid and any other program attempting to open that device hung.
> >>>
> >>> My conslusion is that pktcdvd is eqaully broken for CD-RWs.
> >>
> >> Not surprising. Maybe we should take another stab at killing it
> >> from the kernel.
> >
> > In the commit 4b83e99ee709 ("Revert "pktcdvd: remove driver."") you
> > wrote that we would wait for better user space solution is developed.
> > Any news there?
> >
> > Just asking (I'm in favour to kill the old fart) as you haven't
> > mentioned that in a new attempt.
>
> No work has been done there, to my knowledge. But as the current driver
> is totally broken and people aren't even complaining about that (outside
> of running into that for unrelated reasons), I don't think there's any
> reason for keeping the driver in-tree.
Sure, thanks for clarifications!
--
With Best Regards,
Andy Shevchenko
