Doug, > So tl;dr ? I actually tried. I also spent some time reading the patches two weeks ago. The new series is an improvement over the initial sg v4 posting from last winter. But it still needs work. > Also if my sg v2/v3 documentation targetted the kernel submission > processes between 1998 and 2002, would it be much use today? I think > not. No, but a diff, change bars, or something similar would have been very helpful to clearly identify what's changed between v3 and v4. Just like it's done in standards documents. You have your section 3 bullet list. But the rest of the document is huge and it is not immediately obvious what the v4-specific bits are. > Thank you for repeating the party line. I expected none other. Don't shoot the messenger. This is all documented in detail in: Documentation/process/submitting-patches.rst Please adjust your patch submissions accordingly. Especially the first few paragraphs of section 2 in that document are worth paying attention to. Your patch descriptions typically don't have a problem statement or justification. Why are you making all these changes? Why do we need a v4 in the first place? Why don't the existing ioctls suffice? Why aren't 16 outstanding requests per fd enough? Etc. > And where are the design documents for the sd driver and its ongoing > evolutionary changes? Ever seen anything written about the sr or ses > driver? I think you are missing my point. We don't have gnarly design documents because every change is either a self-contained commit or small series where each patch describes why a change was made. The git log *is* the design document. Each of your bullet features in section 3 ("Changes to sg driver between version 3.5.36 and 4.0") would ideally be submitted as a separate patch series whose individual merits could be discussed on the list. This is in sharp contrast to the "This patchset is big and can be regarded as a driver rewrite" approach that signals a preconceived commitment to a particular set of features and design choices. Why comment on something you can't influence? Who has time to read 22K words on a website and try to find out how those words relate to the posted patches? The only person on linux-scsi that *has* to look at your patches is me. Everybody else is a volunteer you need to entice to invest time and effort in reviewing your work. Quite possibly in their spare time. That's why I suggested that the burden is on you. You need to present your work in a way that engages people, is manageable in terms of time commitment, and makes them feel their investment is worthwhile and appreciated. Please take that into consideration. -- Martin K. Petersen Oracle Linux Engineering