All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: linux-mm@kvack.org
Subject: a couple more oddities(?) in mm code
Date: Mon, 5 Apr 2010 07:39:27 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.00.1004050732180.5342@localhost> (raw)


  (aside:  i am not trying to be an annoying pedant, i am merely
succeeding.  seriously, i'm currently working my way thru the MM code,
in a (possibly vain) attempt to finally understand it, and i
occasionally run across things that just look a bit, well, odd.  but
maybe it's just me.  let me know if any of this is inappropriate.)

  from filemap.c:

        if (!isblk) {
                /* FIXME: this is for backwards compatibility with 2.4 */

is there any compelling reason why any MM code still wants to be 2.4
backwards compatible?  aren't we past that point by now?

  also, from mmu_notifier.c, i find this *really* weird:

=============

int mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm)
{
        return do_mmu_notifier_register(mn, mm, 1);
}
EXPORT_SYMBOL_GPL(mmu_notifier_register);

/*
 * Same as mmu_notifier_register but here the caller must hold the
 * mmap_sem in write mode.
 */
int __mmu_notifier_register(struct mmu_notifier *mn, struct mm_struct *mm)
{
        return do_mmu_notifier_register(mn, mm, 0);
}
EXPORT_SYMBOL_GPL(__mmu_notifier_register);

=============

  as a general rule, i normally expect the difference between two
kernel routines, say, func() and __func(), to be that func() would be
the generally callable one, while __func() would be a lower-level one,
perhaps using func() as a more convenient wrapper.  but the above
shows that those two routines represent *different* invocations of
do_mmu_notifier_register().  that's just not a pattern i'm used to
seeing.  doesn't it kind of fly in the face of kernel coding
standards?

rday
--

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

            Linux Consulting, Training and Kernel Pedantry.

Web page:                                          http://crashcourse.ca
Twitter:                                       http://twitter.com/rpjday
========================================================================

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

                 reply	other threads:[~2010-04-05 11:41 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.00.1004050732180.5342@localhost \
    --to=rpjday@crashcourse.ca \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.