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
