From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH 11/39] ALSA: seq: optimize system_info function to new design Date: Mon, 08 Aug 2016 17:07:24 +0200 Message-ID: References: <1470563355-18368-1-git-send-email-o-takashi@sakamocchi.jp> <1470563355-18368-12-git-send-email-o-takashi@sakamocchi.jp> <3165103a-b4b0-94a6-6fb5-4d7b00dc1ae1@sakamocchi.jp> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 70B1D266BD4 for ; Mon, 8 Aug 2016 17:07:26 +0200 (CEST) In-Reply-To: <3165103a-b4b0-94a6-6fb5-4d7b00dc1ae1@sakamocchi.jp> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Takashi Sakamoto Cc: alsa-devel@alsa-project.org, clemens@ladisch.de List-Id: alsa-devel@alsa-project.org 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 > > > > 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? Meanwhile, the current limitation is reasonable in most cases. Patches with thousands of lines make review more difficult. If your patch exceeds the size, it already indicates that it may be potentially a bad patch. The logic is something similar like 80 chars limitation we have in general. Sometimes a big patch is unavoidable (e.g. writing a new driver from scratch). Or sometimes a bigger patch is acceptable (e.g. when changes are machinery, done purely by a script). But if you wrote some patch by hands and it exceeds the size, you should doubt it at first. Takashi