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