[alsa-devel] [PATCH 11/39] ALSA: seq: optimize system_info function to new design
Takashi Iwai
tiwai at suse.de
Tue Aug 9 14:24:19 CEST 2016
On Tue, 09 Aug 2016 14:15:03 +0200,
Takashi Sakamoto wrote:
>
> On Aug 9 2016 00:07, Takashi Iwai wrote:
> > On Mon, 08 Aug 2016 10:37:21 +0200,
> > Takashi Sakamoto wrote:
> >>
> >> On Aug 8 2016 16:04, Takashi Iwai wrote:
> >>> On Sun, 07 Aug 2016 11:48:47 +0200,
> >>> Takashi Sakamoto wrote:
> >>>>
> >>>> In former commit, actual operations of each ioctl command get argument
> >>>> in kernel space. Copying from/to user space is performed outside of
> >>>> the function.
> >>>>
> >>>> This commit optimizes to the new design.
> >>>>
> >>>> Signed-off-by: Takashi Sakamoto <o-takashi at sakamocchi.jp>
> >>>
> >>> While it's OK to split to small patches if you prefer, you don't have
> >>> to do so. Basically all the rest are doing the same thing (strip
> >>> copy_*_user() and replace to the pointer accesses), and it's rather
> >>> boring to read repeated mails.
> >>
> >> The mail server of alsa-project.org has a limitation of the size of
> >> one message. It shrinks developers to split commit to a small
> >> parts. Not from my taste.
> >
> > Yeah, that's sometimes annoying, indeed. Jaroslav, could you raise
> > the bar to allow larger patches, or drop this restriction?
>
> It's not what I want. I've already followed to the restriction for this
> several years. The restriction is still OK as long as I can split my
> patches as small parts and I'm not objected for them.
>
> You completely puzzled me. Finally, what you'd like me to do?????
You've cut into too small patches. Damn too small.
Of course, too small is much better than too big. That's why I wrote
"it's OK". But it's also a bad taste, after all -- it annoys readers,
since they need to look over the same boring changes again and again.
For avoiding annoyance, such tasks would be better to be grouped in a
certain level, so that readers can take a glance over wider ranges, as
long as all the changes are the more or less same procedure.
Takashi
More information about the Alsa-devel
mailing list