From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f65.google.com ([209.85.214.65]:40142 "EHLO mail-it0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932503AbeFGQfF (ORCPT ); Thu, 7 Jun 2018 12:35:05 -0400 Received: by mail-it0-f65.google.com with SMTP id j186-v6so13416503ita.5 for ; Thu, 07 Jun 2018 09:35:04 -0700 (PDT) MIME-Version: 1.0 References: <20180607150217.jq757ncqopuimbkd@quack2.suse.cz> In-Reply-To: <20180607150217.jq757ncqopuimbkd@quack2.suse.cz> From: Linus Torvalds Date: Thu, 7 Jun 2018 09:34:53 -0700 Message-ID: Subject: Re: [GIT PULL] Fsnotify cleanups To: Jan Kara Cc: linux-fsdevel Content-Type: text/plain; charset="UTF-8" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Jun 7, 2018 at 8:02 AM Jan Kara wrote: > > several fsnotify cleanups unifying handling of different watch > types. Grr. Why is this growing things like "fsnotify_obj_inode()" helpers in ? It has nothing to do with generic fs code. The only things that can possibly use that already have to include fsnotify-specific headers, where things like this belong. It also adds a "struct fsnotify_obj i_fsnotify" to the struct inode, and marks it "packed", so now architectures that have issues with alignment might have issues depending on random changes to 'struct inode'. Plus it (again) causes more disturbance to a core header file that fsnotify shouldn't touch. We had a forward declaration and a pointer. So no. I'm not pulling this. I don't think it's a "cleanup". Maybe it cleans up the fsnotify code, but it uglifies code that is much more important. Linus