Think ioctl()

Interesting idea, but it is more complicated than that. In the sg API, the write() syscall means "start a command" and the read() syscall means "get command completion result". The command may be a SCSI READ, SCSI WRITE, or something else. So you can start a SCSI READ command with a write() syscall, and you can get the command completion of a SCSI WRITE command with a read() syscall. Add in direct I/O, and you will never be able to simplify the API down to the original syscall meanings. Essentially, the sg read()/write() syscalls behave more like ioctl().

Here is an example:

Example: SCSI READ command using direct I/O
allocate buffer to hold data being read
start SCSI READ command via write() syscall to sg, passing address of buffer
wait for command completion; SCSI HBA DMAs directly to buffer
use read() syscall to sg to get command result

If using indirect I/O, you could design an interface where the buffer was passed to the read() syscall at command completion (although the sg driver doesn't work like that). But using direct I/O, the kernel needs the buffer when the command is started, so it is passed in the write() syscall. So there is no way to map "start a command" to the original meaning of the write() (or writev()) syscall using direct I/O. It makes more sense to think of it as an ioctl().