linux-kernel - Re: [PATCH 00/10] autofs4 - rename autofs4 to autofs

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] [day] [month] [year] [list]

Date:	Tue, 03 Sep 2013 20:47:13 +0800
From:	Ian Kent <raven@...maw.net>
To:	Michael Tokarev <mjt@....msk.ru>
Cc:	linux-next@...r.kernel.org,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	autofs mailing list <autofs@...r.kernel.org>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 00/10] autofs4 - rename autofs4 to autofs

On Tue, 2013-09-03 at 15:28 +0400, Michael Tokarev wrote:
> 31.08.2013 15:42, Ian Kent wrote:
> [...]
> > By leaving a Kconfig and Makefile in fs/autofs4 (to build autofs4.ko)
> > with a deprication message sub-system maintainers and other users will
> > make any needed changes before these are removed after two kernel versions.
> > IMHO the presence of the warning is reason enough to leave a build stub
> > rather than do a straight out rename.
> 
> Why do you want to continue building autofs4.ko? (or allowing to)
> What's actually wrong with a stright rename?
> If the new module can be auto-loaded by both name (by providing an
> alias), there's no need to keep ability to build autofs4.ko, I think.

The hope is that within two subsequent kernel versions, when it is
removed, people that need to change will have noticed this and made the
needed changes. That's scripts that may have looked for autofs4.ko to
work around the auto-load problem, aliases that won't work now, kernel
configurations, etc...

The configuration message for autofs4 now says these things and says the
module is going to be removed.

> 
> Well, maybe except of the case when autofs is needed in initramfs (like
> for systemd).  For this, indeed, you can keep autofs4.ko which is a
> dummy depending on autofs.ko...
> 
> > Ian Kent (10):
> >       autofs4 - coding style fixes
> >       autofs4 - fix string.h include in auto_dev-ioctl.h
> >       autofs4 - move linux/auto_dev-ioctl.h to uapi/linux
> >       autofs - merge auto_fs.h and auto_fs4.h
> >       autofs - use autofs instead of autofs4 everywhere
> >       autofs - copy autofs4 to autofs
> >       autofs - create autofs Kconfig and Makefile
> >       autofs - update fs/autofs4/Kconfig
> >       autofs - update fs/autofs4/Makefile
> >       autofs - delete fs/autofs4
> 
> By doing it this way, you're losing all git history.
> If you perform stright rename and git detects it, you
> can use, eg, git log --follow to see whole hostory
> across rename.  This way you create new files without
> history.
> 
> So I strongly shuggest actually renaming the subdirectory
> (together with appropriate kconfig/makefile changes so
> things are bisectable), and creating the stubs after this.
> 
> Thanks,
> 
> /mjt
> --
> To unsubscribe from this list: send the line "unsubscribe autofs" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


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