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.
--
Jens Axboe
