[arch-general] [cdrecord] Problems with original cdrecord on latest linux kernel

[Lukáš Jirkovský]

On 17 June 2012 01:08, Tom Gundersen <teg at jklm.no> wrote:
> On Sat, Jun 16, 2012 at 9:14 PM, Lukáš Jirkovský <l.jirkovsky at gmail.com> wrote:
>> On 11 June 2012 12:05, Joerg Schilling
>> <Joerg.Schilling at fokus.fraunhofer.de> wrote:
>>> BTW: the fact that there is no documentation[1] for this new driver looks like a
>>> reason for not including it.
>>
>> That's a perfectly valid reason.
>
> FWIW: this is up to the kernel devs, and not us. 'bsg' is
> supported/loaded because the kernel says so. The only thing that
> changed recently was that a hack was removed from udev to foricbly
> load the 'sg' module. The reason this hack was needed is that (as far
> as i understand) the 'sg' module does not have support for the being
> automatically loaded as almost all other modules (including 'bsg')
> does.

Yep, we can do hardly anything about that. However, I completely
understand why Joerg doesn't want to implement it when there's no
documentation. Using some badly/undocumented interfaces is a nightmare
and, as Joerg said, it becomes even more funny when the interface
changes as you don't have a slight idea what parts of the API are
considered stable and public. But as I said in my previous post the
reason why there's no documentation might be that it has the same
interface as the 'sg' driver…

> A way around this is to add back the hack but make it specific to the
> packages that need it (such as cdrecord), rather than having it on all
> systems. This is essentially what the modules-load.d fragment I
> proposed does.
>
> -t

I implemented the modules-load.d thing in the cdrtools 3.01a07-4.
Thank you for that.

Lukas