Date: Thu, 13 Nov 2014 11:38:52 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: Benjamin Kaduk <bjk@freebsd.org>, freebsd-arch@freebsd.org, fs@freebsd.org, Jonathan Anderson <jonathan@FreeBSD.org>, arch@freebsd.org Subject: Re: Removal of kern_xxx() no-at variants. Message-ID: <20141113093852.GU17068@kib.kiev.ua> In-Reply-To: <20141112223144.GA90037@stack.nl> References: <20141112132451.GM17068@kib.kiev.ua> <201411121014.04482.jhb@freebsd.org> <alpine.GSO.1.10.1411121449340.27826@multics.mit.edu> <5463C39C.2010204@FreeBSD.org> <20141112223144.GA90037@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 12, 2014 at 11:31:45PM +0100, Jilles Tjoelker wrote:
> On Wed, Nov 12, 2014 at 05:01:24PM -0330, Jonathan Anderson wrote:
> > A thought:
>
> > If we're only going to have one of {kern_open,kern_openat}, might it
> > make sense to keep the shorter name rather than the longer one?
> > kern_openat as a name seems meaningful to me only if we're trying to
> > disambiguate it from an also-existent-but-different-meaning kern_open.
>
> The name kern_openat makes sense in that the functionality is like the
> openat() system call.
I like the proposal, but think that it is premature, unfortunately.
Issue is the MFC to stable branches, which still have old functions
used in code. I do not mean merge of this change to stable, but
other merges which intersect with the at/no-at modifications. Having
kern_open() as different functions in HEAD and stable is too confusing
without real value IMO.
Note that it is possible to partially MFC the commit into stable, leaving
the removal of the no-at variants out of the patch.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141113093852.GU17068>