Re: [PATCH v5 01/40] scsi: define all additional sense codes and their qualifiers

[Damien Le Moal <dlemoal@kernel.org>]

On 9/8/26 10:20, Bart Van Assche wrote:
> On 9/7/26 5:30 PM, Damien Le Moal wrote:
>> Sure, easy to do. But I have not seen any compilation errors. So their is
>> currently no clash, but indeed, this is at the mercy of any change in included
>> files. So better safe here and I will rename. Not sure what a good prefix is
>> though... Maybe SCSI_WARNING ? Or SCSI_SENSE_WARNING ? Any better suggestion?
> 
> As you know any enumeration label ends up in the global namespace so
> it's considered a good practice to make the names of all enumeration
> labels of the same enumeration type start with the same prefix. Would
> it be acceptable to make all labels in enum scsi_sense_code start with
> the SCSI_SENSE_ prefix? The labels in enum scsi_sense_key probably could
> also use a prefix? Constants with names like "NOT_READY" and "COMPLETED"
> might also be defined in other kernel headers. Would SSK_ (SCSI SENSE
> KEY) be a good prefix?

The sense keys have been defined as they are for years, and there are no issues
that I know of about that. So I am not going to touch that in this series.
For the sense codes and their combination with sense code qualifiers, I could
prefix everything with SSC_ but I do not really see the point given that most
definitions are very peculiar as they follow mostly the exact naming of the T10
list. I did that in purpose so that it is easier to code/debug while looking at
T10 specifications. I did shorten some names (e.g. LOGICAL UNIT -> LU) to try
to avoid excessively long names as these force very long code lines, which is
not nice. Adding an SSC_ prefix will go against that goal.

The 8-bits sense code definitions are already prefixed with ASC_. The sense
code + 0x00 qualifier definitions are not prefixed, so I renamed WARNING and
WRITE_ERROR with the SSC_ prefix added. That should be enough I think.
As mentioned in my initial email, a make allyesconfig is fine so there are no
name clashes that I can see, even without renaming anything.


-- 
Damien Le Moal
Western Digital Research