linux-kernel - Re: [PATCH 1/3] filesystem notification: create fs/notify to contain all fs notification

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20081216104219.06D0.KOSAKI.MOTOHIRO@jp.fujitsu.com>
Date:	Tue, 16 Dec 2008 10:46:52 +0900 (JST)
From:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
To:	Eric Paris <eparis@...hat.com>
Cc:	kosaki.motohiro@...fujitsu.com, linux-kernel@...r.kernel.org,
	hch@...radead.org, akpm@...ux-foundation.org
Subject: Re: [PATCH 1/3] filesystem notification: create fs/notify to contain all fs notification

> > 1) this mail only contain Kconfig and Makefile changing patch.
> >    iow, this patch doesn't contain file moving information.
> >    iow, patch statics and actual patch are different.
> > 2) your latter patch doesn't depend on this patch.
> >    this patch doesn't have justification.
> >    I recommend to separate this patch.
> 
> It is there, it is just in the git -M rename diff output rather than
> "normal" diff.  See the sections like:
> 
> diff --git a/fs/dnotify.c b/fs/notify/dnotify/dnotify.c
> similarity index 100%
> rename from fs/dnotify.c
> rename to fs/notify/dnotify/dnotify.c
> 
> This type of patch can be applied directly to your git tree and makes
> review trivial.....
> 
> If people who will put this into a subsystem would prefer the long diff
> I'll gladly resend.

Oh sorry ;)
To be honest, almost linux-mm develper are using quilt and I don't use
git almost case.


> I'll agree it isn't required but the other 2 aren't going to apply
> without it, and it does clean up fs.  I'd much rather get this early
> than in the middle somewhere since others are also looking at changing
> this subsystem at the same time....     It can be dropped it others
> agree....

I don't objection this cleanup. but the patch series should be made by
logical group.
I don't like to contain independent cleanup patch ;-)


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/