sys/linux: add basic descriptions for BSG devices

[fellair]

BSG is a block layer version of SG driver with its own devices, which can be found in /dev/bsg/*. Currently, syzkaller barely touches related code in block/ and drivers/scsi/ source directories, so update the descriptions to nudge the fuzzer in the right direction.

Specifically,

• create a separate description file dev_bsg.txt;
• move openat$bsg from sys.txt and fix the way devices in question are accessed;
• describe necessary syscalls and structs, most importantly, sg_io_v4.
• add a few TODOs to address later.

P.S. No descriptions were removed, only expanded. Coverage is slightly improved compared to syzbot one in block/bsg.c and drivers/scsi/scsi_bsg.c among some others.
P.P.S. I plan to fix TODOs at a later date in a separate PR, once I understand more about SCSI and BSG.

[a-nogikh]

Depends on whether these need to already exist (in which case it's better to hard-code them here) or they can be arbitrary. If they can be arbitrary, something like this could be an option:

syzkaller/sys/linux/security_smack.txt

Lines 110 to 126 in d6cdfb8

	smack_ipv6 {
	d1 fmt[hex, int8]
	sp1 const[':', int8]
	d2 fmt[hex, int8]
	sp2 const[':', int8]
	d3 fmt[hex, int8]
	sp3 const[':', int8]
	d4 fmt[hex, int8]
	sp4 const[':', int8]
	d5 fmt[hex, int8]
	sp5 const[':', int8]
	d6 fmt[hex, int8]
	sp6 const[':', int8]
	d7 fmt[hex, int8]
	sp7 const[':', int8]
	d8 fmt[hex, int8]
	} [packed]

But AFAIK syzkaller could be validating open inputs, so it may require the path to be an explicit string rather than a struct.

[fellair]

Provided necessary config options are enabled (and they are in according syzbot instances), necessary devices are created automatically. The names described in .txt file seem to be consistent enough that I opted to hard-code them. I am looking into ways to spawn more of them (via config options and similar to null_blk) but this solution is stable enough.

Technically, they could be of a:b:c:d format, so it makes sense to look into other options, like the one you suggested. For now though it may fine, till I come up with a more elegant solution.

[a-nogikh]

For now a list of string consts is definitely OK.

[a-nogikh]

Thanks!