linux-kernel - Re: [PATCH 1/9] Add yaffs Kconfig and Makefile

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: <201011050958.39020.manningc2@actrix.gen.nz>
Date:	Fri, 5 Nov 2010 09:58:38 +1300
From:	Charles Manning <manningc2@...rix.gen.nz>
To:	Greg KH <greg@...ah.com>
Cc:	cdhmanning@...il.com, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 1/9] Add yaffs Kconfig and Makefile

On Thursday 04 November 2010 06:46:07 Greg KH wrote:
> On Thu, Nov 04, 2010 at 05:53:16AM +1300, cdhmanning@...il.com wrote:
> > From: Charles Manning <cdhmanning@...il.com>
> >
> > Adding yaffs2 file system.
> >
> > Signed-off-by: Charles Manning <cdhmanning@...il.com>
> > ---
> >  fs/yaffs2/Kconfig  |  190
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/yaffs2/Makefile |
> >   17 +++++
>
> Don't do this as your first patch, make it your last one.  Otherwise the
> build will break when you apply this one to the tree.
> Remember, we need to be able to have a correct build at every patch in
> the whole development series, otherwise tools like 'git bisect' will not
> work properly.

I left the actual hook in to the tree building to the last patch which changes 
fs/Kconfig and fs/Makefile.  Thus building the whole of Linux would not 
break.

I suppose the best is to put all the Kconfigs and Makefile changes in the last 
patch.

>
> Also, is your goal to get this cleaned up good enough to get it into .38
> in the "real" place in the kernel, or do you want to see it go through
> staging and take a bit longer to get everything cleaned up properly
> before moving to the "real" location?

My goal it to get this into mainline, .38 preferred.

I am a complete newbie when it comes to this process. What's the best path to 
getting there? 

My preference is to keep cleaning up code in yaffs.net and patching from there 
as this will keep the trees closer together and minimise clerical issues.

It is also a goal to keep the multi-kernel version of the code going in 
yaffs.net so  that there is always a backport on tap. This is an important 
issue for the embedded folk.

>From what you have said it sounds like skipping staging might be better, but I 
have insufficient understanding of the process to understand why. I'll talk 
to some people I know that understand this better.

Thanks

Charles

--
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/