include/scsi/scsi.h replace u8 in 2.5.69

Here is a simple patch to replace the single occurrence of "u8" with "u_char" in include/scsi/scsi.h .

While working on an application (to test sgbind) that needs to include the kernel rather than the glibc headers, it is a nuisance to have to add:
typedef unsigned char u8;
before including /usr/src/linux/include/scsi/scsi.h

Perhaps we should be moving toward the official C99
typedef: uint8_t which is defined in stdint.h

Doug Gilbert

@@ -201,7 +201,7 @@
  * ScsiLun: 8 byte LUN.
  */
 typedef struct scsi_lun {
-	u8 scsi_lun[8];
+	u_char scsi_lun[8];
 } ScsiLun;
 
 /*

That's wrong. No userland should include kernwel headers. (and u_char is a non-standard type, too).

Agreed. And like Douglas guessed, uint8_t is preferred over u_char :)

Jeff

Christoph,
That's naive. In some case glibc's headers and libraries (e.g. mknod) are an impediment to development.

If I add one define to ~linux/include/scsi/sg.h just how long do you think it takes for it to appear in /usr/include/scsi/sg.h?
It can take over a year in my experience.

Put another way, the sg.h header that applications use should match the sg driver in the kernel not the glibc version. The glibc maintainers add nothing to the interface (apart from inertia and some bugs once in a while).

Applications that include sg.h typically include scsi.h as well. Only when I change sg.h does this problem arise.

It is one thing to state a policy (e.g. "no user program should include kernel headers") it is another thing to gratuitously break those few programs that have good reason not to follow that policy.

Doug Gilbert

As long as it takes you to send the same diff to Ullrich.

What kernel? I run everything from 2.2.2x + local hacks to latest 2.5 on one box.

So get declarations for u8 into your program. It's a kernel header for a reason and if you ignore the advise _you_ have to work around the problems arising from it not the kernel.

Consider: the same binaries are used on a wide range of kernels.
Consider: the same sources are compiled on machines with a wide range of installed kernel sources.

It is undesirable that recompilation is needed when a kernel is upgraded (or downgraded).

Thus, the robust setup uses its own copy of the headers, or perhaps uses something like

#include <header.h>
#ifndef MY_CONSTANT
#define MY_CONSTANT 12345
#endif

to make sure that things compile with old and new *libc, with old and new kernels.

Next, this robust setup must make sure that things not only compile but also run, i.e., must be prepared to deal with EINVAL or ENOSYS etc in case it is run on a kernel that does not yet know about this new stuff.

Andries

[There is an different case for a private copy of the headers:
the kernel headers change all the time, and sometimes such changes cause obscure and difficult-to-debug errors in utilities. I still recall the case, many years ago, of a struct field that was made unsigned, causing a change in semantics for a comparison. User space software is easier to debug when the corresponding binary does not depend in obscure ways on the kernel source installed when it was compiled.]