All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Gladkov <gladkov.alexey@gmail.com>
To: Lucas De Marchi <lucas.de.marchi@gmail.com>
Cc: mahatma@eu.by, linux-modules <linux-modules@vger.kernel.org>
Subject: Re: modinfo must show real module info, not context if filename set
Date: Wed, 26 Feb 2020 23:36:28 +0100	[thread overview]
Message-ID: <20200226223628.ncpovmhd6kpyph2l@comp-core-i7-2640m-0182e6> (raw)
In-Reply-To: <CAKi4VAJFM0oM5r0oUtgT0oChH2q6+5YNq_46e01ih4j5qXsCxQ@mail.gmail.com>

On Wed, Feb 26, 2020 at 11:36:00AM -0800, Lucas De Marchi wrote:
> On Wed, Feb 26, 2020 at 10:33 AM Alexey Gladkov
> <gladkov.alexey@gmail.com> wrote:
> >
> > On Wed, Feb 26, 2020 at 04:53:45AM +0200, Denis Kaganovich wrote:
> > > After commit e7e2cb61fa9f1db3429d91ef6accff549500d268, even if real filename
> > > passed - modinfo show info from context (so, I got built-in info from
> > > running
> > > kernel, but asking for new kernel's external module). This behaviour
> > > unobvious
> > > and incompatible with pre-v27. Simple use fake context for filename - IMHO
> > > much less ugly then current results.
> >
> > Can you give an example of this misbehavior ?
> >
> > I have a two kernel directories (generic and current) with
> > modules.builtin.modinfo:
> >
> > $ ls -1 /lib/modules/{5.2.0-generic,`uname -r`}/modules.builtin.modinfo
> > /lib/modules/5.2.0-generic/modules.builtin.modinfo
> > /lib/modules/5.2.0-current/modules.builtin.modinfo
> >
> > The ext4 module is built into both:
> >
> > $ tr '\0' '\n' < /lib/modules/`uname -r`/modules.builtin.modinfo |grep ^ext4.description
> > ext4.description=Fourth Extended Filesystem
> >
> > $ tr '\0' '\n' < /lib/modules/5.2.0-generic/modules.builtin.modinfo |grep ^ext4.description
> > ext4.description=Fourth Extended Filesystem
> >
> > Now I have build this module separately and put it into the tree:
> 
> that's why you don't have this problem. If you just build a new
> ext4.ko module and give it
> in the command line without putting it into the tree, then this
> problem would be triggered.

Ouch, I see. The phrase "new kernel's external module" confused me because
usually the modules for the new kernel are in the tree. My bad.

> $ ~/p/kmod/tools/modinfo fs/ext4/ext4.ko
> filename:       /home/ldmartin/p/gfx-internal/drm-intel-internal/fs/ext4/ext4.ko
> modinfo: ERROR: could not get modinfo from 'ext4': No such file or directory
> 
> $ modinfo fs/ext4/ext4.ko
> filename:       /home/ldmartin/p/gfx-internal/drm-intel-internal/fs/ext4/ext4.ko
> softdep:        pre: crc32c
> license:        GPL
> description:    Fourth Extended Filesystem
> author:         Remy Card, Stephen Tweedie, Andrew Morton, Andreas
> Dilger, Theodore Ts'o and others
> alias:          fs-ext4
> alias:          ext3
> alias:          fs-ext3
> alias:          ext2
> alias:          fs-ext2
> depends:        mbcache,jbd2
> retpoline:      Y
> intree:         Y
> name:           ext4
> vermagic:       5.4.17+ SMP preempt mod_unload
> 
> Lucas De Marchi

-- 
Rgrds, legion


      reply	other threads:[~2020-02-26 22:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26  2:53 modinfo must show real module info, not context if filename set Denis Kaganovich
2020-02-26 18:31 ` Alexey Gladkov
2020-02-26 19:36   ` Lucas De Marchi
2020-02-26 22:36     ` Alexey Gladkov [this message]

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=20200226223628.ncpovmhd6kpyph2l@comp-core-i7-2640m-0182e6 \
    --to=gladkov.alexey@gmail.com \
    --cc=linux-modules@vger.kernel.org \
    --cc=lucas.de.marchi@gmail.com \
    --cc=mahatma@eu.by \
    /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.