Comment # 48 on bug 1036463 from Martin Wilck

(In reply to Lee Duncan from comment #6)

> Actually it's udev rules that rely on it:
> 
> > zsh# grep -rl sg /usr/lib/udev/rules.d
> > /usr/lib/udev/rules.d/55-scsi-sg3_id.rules
> > /usr/lib/udev/rules.d/58-scsi-sg3_symlink.rules
> > /usr/lib/udev/rules.d/60-persistent-storage-tape.rules
> > /usr/lib/udev/rules.d/40-libgphoto2.rules

Let's clarify: 

1. 55-scsi-sg3_id.rules handles only block devices, which support SG_IO ioctls
even if the sg driver isn't loaded (via scsi_cmd_blk_ioctl(), in all kernels
since 4.0 at least). Thus it doesn't depend on the sg driver.

2. 58-scsi-sg3_symlink.rules doesn't do any ioctls, thus doesn't depend on the
sg driver.

3. 60-persistent-storate-tape.rules accesses only *bsg* devices and thus
doesn't depend on the sg driver.

4. 60-persistent-storage.rules (missing in the above list) contains scsi_id
calls which do SG_IO ioctls, but only on sd and sr devices, so the same
argument as for 1. applies.

5. 40-libgphoto2.rules does not require the sg driver either. It checks for
KERNEL=="sg[0-9]". It handles events generated by sg, which means that the sg
module is loaded already when the rule is triggered. Thus it doesn't depend on
early loading of the sg module. 

That said, autodetection of libgphoto devices may depend on sg being loaded.
But that should probably be handled in the libgphoto2 itself. Adding Marcus
Meissner as the libgphoto2 maintainer.

Summarizing, unless I'm overlooking something essential, the early loading of
the sg driver is really just a relict from the past and could be dropped.