Make ltotape for Linux buildable

[piste-jp]

This commit includes following changes

• Make ltotape backend for Linux buildable
• Add --enable-checkonly build for detecting build break because of the backend I/F change in the LTFS project (May be checked by Travis CI on the LTFS project)
• Add .gitignore to ignore some files created by the auto tools

Please confirm that this PR doesn't break the NetBSD build.

[manu0401]

It looks good to me and it builds on NetBSD with this change, but is it a good idea to modify src/tape_drivers/linux/ltotape/ltotape_platform.c ? The change is only about an include reordering and trailing spaces suppression, but that adds burden to tracking upstream.

[piste-jp]

I believe the reordering of src/tape_drivers/linux/ltotape/ltotape_platform.c is required. The code can't be built on Linux (at least RHEL7) without this reordering.

Previously, ltotape_platform.c includes scsi/scsi.h and then include ltotape_diag.h. ltotape_diag.h includes IBM_tape.h, IBM_tape.h includes ibm_tape.h. In ibm_tape.h and then ibm_tape.h includes ssc_op_codes.h. ssc_op_codes.h has the enum ssc_codes like below.

enum ssc_codes {
	ALLOW_OVERWRITE                 = 0x82,
	DISPLAY_MESSAGE                 = 0xC0,
	ERASE                           = 0x19,
	FORMAT_MEDIUM                   = 0x04,
	LOAD_UNLOAD                     = 0x1B,
	LOCATE10                        = 0x2B,
	LOCATE16                        = 0x92,
	PREVENT_ALLOW_MEDIUM_REMOVAL    = 0x1E,
	READ                            = 0x08,
	READ_BLOCK_LIMITS               = 0x05,
	READ_DYNAMIC_RUNTIME_ATTRIBUTE  = 0xD1,
	READ_POSITION                   = 0x34,
	READ_REVERSE                    = 0x0F,
	RECOVER_BUFFERED_DATA           = 0x14,
	REPORT_DENSITY_SUPPORT          = 0x44,
	REWIND                          = 0x01,
	SET_CAPACITY                    = 0x0B,
	SPACE6                          = 0x11,
	SPACE16                         = 0x91,
	STRING_SEARCH                   = 0xE3,
	VERIFY                          = 0x13,
	WRITE                           = 0x0A,
	WRITE_DYNAMIC_RUNTIME_ATTRIBUTE = 0xD2,
	WRITE_FILEMARKS6                = 0x10,
};

But on the other hand, scsi/scsi.h has #define ERASE 0x19 and some other conflicted definitions. They breaks a build because C preprocessor replaces enum ssc_codes like

enum ssc_codes {
	ALLOW_OVERWRITE                 = 0x82,
	DISPLAY_MESSAGE                 = 0xC0,
	0x19                          = 0x19,
	FORMAT_MEDIUM                   = 0x04,
	LOAD_UNLOAD                     = 0x1B,
	LOCATE10                        = 0x2B,
	LOCATE16                        = 0x92,
	PREVENT_ALLOW_MEDIUM_REMOVAL    = 0x1E,
	READ                            = 0x08,
	READ_BLOCK_LIMITS               = 0x05,
	READ_DYNAMIC_RUNTIME_ATTRIBUTE  = 0xD1,
	READ_POSITION                   = 0x34,
	READ_REVERSE                    = 0x0F,
	RECOVER_BUFFERED_DATA           = 0x14,
	REPORT_DENSITY_SUPPORT          = 0x44,
	REWIND                          = 0x01,
	SET_CAPACITY                    = 0x0B,
	SPACE6                          = 0x11,
	SPACE16                         = 0x91,
	STRING_SEARCH                   = 0xE3,
	VERIFY                          = 0x13,
	WRITE                           = 0x0A,
	WRITE_DYNAMIC_RUNTIME_ATTRIBUTE = 0xD2,
	WRITE_FILEMARKS6                = 0x10,
};

That is the reason why I change the order of include files. It looks the ltotape driver is including scsi/scsi.h because of SCSI_IOCTL_GET_IDLUN. But this call is not used in the sg drive at this time. So I didn't realize that scsi/scsi.hhas same definitions.

In the future, it is good to avoid such kind of conflict but I believe this work around is the best way at this time.

[piste-jp]

In the sg driver, SG_GET_SCSI_ID can be used instead. So there is no reason to include scsi/scsi.h at all.

I need to consider we really require to avoid the conflicts or not.

[manu0401]

On Wed, Feb 27, 2019 at 12:01:25AM -0800, Atsushi Abe wrote: I need to consider we really require to avoid the conflicts or not.

Well, the reordering is a two line diff, not such a big deal, but what about trailing spaces?

…

-- Emmanuel Dreyfus manu@netbsd.org

[piste-jp]

I (and also original members of the LTFS project) just hate trailing spaces....

The code convention of the LTFS project doesn't allow that. So I'm using the editor configuration to remove trailing white space at save files. (It's not an intention but my editor cleanup them automatically.)

Do you want to keep them really?

[manu0401]

On Wed, Feb 27, 2019 at 12:16:39AM -0800, Atsushi Abe wrote: I (and also original members of the LTFS project) just hate trailing spaces....

I can understand that and I am willing to nuke them whenever possible, but here that just enlarges the diff against upstream without real benefit beyond aestetics.

…

-- Emmanuel Dreyfus manu@netbsd.org

[piste-jp]

OK. I will create another PR.