Comment # 59 on bug 1036463 from Martin Wilck

As I've pushed the udev rule solution to the latest suse-module-tools package,
I've started having doubts again. But I still think the solution is the best
one.
Documenting my thoughts here for future reference.

While the udev solution has the desired effect in terms of module load
ordering, it has the disadvantage that an additional call to udev's "kmod"
built-in is made for every SCSI device. That call is pretty cheap, as the
expensive part (kmod initialization, configuration parsing) is done during udev
startup. After its first invocation, the RUN{builtin}="kmod load sg" call comes
down to a read() on /sys/module/sg/initstate. I suppose it doesn't do much
harm.

FTR, the alternatives are

 1 Simply add sg.conf in its current form to suse-module-tools, as originally
requested by Frack (comment 26, disadvantage: loading sg on non-SCSI systems)
 2 SUSE specific kernel patch with compiled-in alias (comment 5, disadvantage:
one more SUSE kernel patch with no chance of being upstreamed)
 3 Drop early loading of sg altogether (discussion in comment 48 ff.,
disadvantage: possible regressions in some user space tools, no concrete
evidence)

Opinions welcome.