On 17 June 2012 01:08, Tom Gundersen <teg@jklm.no> wrote:
On Sat, Jun 16, 2012 at 9:14 PM, Lukáš Jirkovský <l.jirkovsky@gmail.com> wrote:
On 11 June 2012 12:05, Joerg Schilling <Joerg.Schilling@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