Re: [PATCH 00/19] sg: v4 interface, rq sharing + multiple rqs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux