All of lore.kernel.org
 help / color / mirror / Atom feed
* scripts/Makefile.modinst: removing module path M from module destination is not working for some cases
@ 2018-11-08 11:26 Mikolaj Ch
  2018-11-12  5:31 ` Masahiro Yamada
  0 siblings, 1 reply; 3+ messages in thread
From: Mikolaj Ch @ 2018-11-08 11:26 UTC (permalink / raw)
  To: yamada.masahiro, michal.lkml; +Cc: linux-kbuild

Hi,

I noticed a problem while installing external module with command:
make M=dir modules_install

For me it appeared in two separate cases:
- when 'dir' includes symbolic link
- when 'dir' includes double slash.

For this two cases module is installed to:
lib/modules/<kernel_version>/extra/<'dir>'/<module_name>.ko
instead of
lib/modules/<kernel_version/extra/<module_name>.ko

I've traced the problem and it appeared to be in:
scripts/Makefile.modinst in line:

in line 12 the path to module is taken from MODVERDIR/*.mod file:
__modules := $(sort $(shell grep -h '\.ko$$' /dev/null $(wildcard
$(MODVERDIR)/*.mod)))

and then directory part of this path is going to be removed with subst
function in line 30:
ext-mod-dir = $(INSTALL_MOD_DIR)$(subst $(patsubst
%/,%,$(KBUILD_EXTMOD)),,$(@D))

but it fails since KBUILD_EXTMOD is not evaluated path (can include
symlink or double slash) and @D is direct/evaluated path from *.mod
file.

-------------------------
the same in more details:
-------------------------

In kernel Makefile the following variables are set:
KBUILD_EXTMOD = $M
MODVERDIR = $KBUILD_EXTMOD/.tmp_versions


in scripts/Makefile.modinst in lines:
__modules := $(sort $(shell grep -h '\.ko$$' /dev/null $(wildcard
$(MODVERDIR)/*.mod)))
modules := $(patsubst %.o,%.ko,$(wildcard $(__modules:.ko=.o)))

The path in $MODVERDIR is evaluated correctly by shell (symbolic link
is followed and double slash is interpreted as single slash)
and the path to the module $modules is taken form $(MODVERDIR)/*.mod file).

The $modules is then passed to __modinst function as $@ where in line:
ext-mod-dir = $(INSTALL_MOD_DIR)$(subst $(patsubst
%/,%,$(KBUILD_EXTMOD)),,$(@D))

subst function substitutes text from $KBUILD_EXTMOD to empty string in
directory part of $@ (@D) but here KBUILD_EXTMOD is different then @D.


Can't directory part be remove differently if using absolute paths to
avoid such problems ?

Regards,
  Mikolaj Chadzynski

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: scripts/Makefile.modinst: removing module path M from module destination is not working for some cases
  2018-11-08 11:26 scripts/Makefile.modinst: removing module path M from module destination is not working for some cases Mikolaj Ch
@ 2018-11-12  5:31 ` Masahiro Yamada
  2018-11-12 12:54   ` Mikolaj Ch
  0 siblings, 1 reply; 3+ messages in thread
From: Masahiro Yamada @ 2018-11-12  5:31 UTC (permalink / raw)
  To: mikich7777; +Cc: Michal Marek, Linux Kbuild mailing list

On Thu, Nov 8, 2018 at 8:27 PM Mikolaj Ch <mikich7777@gmail.com> wrote:
>
> Hi,
>
> I noticed a problem while installing external module with command:
> make M=dir modules_install
>
> For me it appeared in two separate cases:
> - when 'dir' includes symbolic link
> - when 'dir' includes double slash.
>
> For this two cases module is installed to:
> lib/modules/<kernel_version>/extra/<'dir>'/<module_name>.ko
> instead of
> lib/modules/<kernel_version/extra/<module_name>.ko
>
> I've traced the problem and it appeared to be in:
> scripts/Makefile.modinst in line:
>
> in line 12 the path to module is taken from MODVERDIR/*.mod file:
> __modules := $(sort $(shell grep -h '\.ko$$' /dev/null $(wildcard
> $(MODVERDIR)/*.mod)))
>
> and then directory part of this path is going to be removed with subst
> function in line 30:
> ext-mod-dir = $(INSTALL_MOD_DIR)$(subst $(patsubst
> %/,%,$(KBUILD_EXTMOD)),,$(@D))
>
> but it fails since KBUILD_EXTMOD is not evaluated path (can include
> symlink or double slash) and @D is direct/evaluated path from *.mod
> file.
> -------------------------
> the same in more details:
> -------------------------
>
> In kernel Makefile the following variables are set:
> KBUILD_EXTMOD = $M
> MODVERDIR = $KBUILD_EXTMOD/.tmp_versions
>
>
> in scripts/Makefile.modinst in lines:
> __modules := $(sort $(shell grep -h '\.ko$$' /dev/null $(wildcard
> $(MODVERDIR)/*.mod)))
> modules := $(patsubst %.o,%.ko,$(wildcard $(__modules:.ko=.o)))
>
> The path in $MODVERDIR is evaluated correctly by shell (symbolic link
> is followed and double slash is interpreted as single slash)
> and the path to the module $modules is taken form $(MODVERDIR)/*.mod file).


I tested it, but it did not happen to me.

The path in $(MODVERDIR) reflects
the directory path given via M= option for 'make modules'.


I guess you passed a normalized path to
'make M=<dir> modules'
then, a non-normalized path to
'make M=<dir> modules_install'
Didn't you ?



> The $modules is then passed to __modinst function as $@ where in line:
> ext-mod-dir = $(INSTALL_MOD_DIR)$(subst $(patsubst
> %/,%,$(KBUILD_EXTMOD)),,$(@D))
>
> subst function substitutes text from $KBUILD_EXTMOD to empty string in
> directory part of $@ (@D) but here KBUILD_EXTMOD is different then @D.
>
>
> Can't directory part be remove differently if using absolute paths to
> avoid such problems ?


I think  this is a hypothetical problem, like
   What if a user passed different passes for
  'make modules' and 'make modules_install' ?



         $ make -C <path_to_kernel_src> M=$PWD

is the idiom to build external modules.

M=$PWD will do a good job for you.


See Documentation/kbuild/modules.txt





> Regards,
>   Mikolaj Chadzynski



-- 
Best Regards
Masahiro Yamada

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: scripts/Makefile.modinst: removing module path M from module destination is not working for some cases
  2018-11-12  5:31 ` Masahiro Yamada
@ 2018-11-12 12:54   ` Mikolaj Ch
  0 siblings, 0 replies; 3+ messages in thread
From: Mikolaj Ch @ 2018-11-12 12:54 UTC (permalink / raw)
  To: yamada.masahiro; +Cc: michal.lkml, linux-kbuild

Yes, the result is the same as in example you given.
There is a difference in the path in *.mod file (created during module
compile time) and M given to install.
But the situation is a more real one. I compile external module
outside of kernel tree and then I'm not using make M=<dir> modules at
all.
For me external module path can change so the M given to install is a
symbolic link. It can also be a path created by by build script so it
can include double slash (so yes, I'm giving non-normalized path to
make modules_install).
But still I think this is a problem because we should not assume that
the path given to install is normalized one and the same as given for
compilation.
If we can find the module to be installed we should also install it in
a correct path.
On Mon, Nov 12, 2018 at 6:32 AM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> On Thu, Nov 8, 2018 at 8:27 PM Mikolaj Ch <mikich7777@gmail.com> wrote:
> >
> > Hi,
> >
> > I noticed a problem while installing external module with command:
> > make M=dir modules_install
> >
> > For me it appeared in two separate cases:
> > - when 'dir' includes symbolic link
> > - when 'dir' includes double slash.
> >
> > For this two cases module is installed to:
> > lib/modules/<kernel_version>/extra/<'dir>'/<module_name>.ko
> > instead of
> > lib/modules/<kernel_version/extra/<module_name>.ko
> >
> > I've traced the problem and it appeared to be in:
> > scripts/Makefile.modinst in line:
> >
> > in line 12 the path to module is taken from MODVERDIR/*.mod file:
> > __modules := $(sort $(shell grep -h '\.ko$$' /dev/null $(wildcard
> > $(MODVERDIR)/*.mod)))
> >
> > and then directory part of this path is going to be removed with subst
> > function in line 30:
> > ext-mod-dir = $(INSTALL_MOD_DIR)$(subst $(patsubst
> > %/,%,$(KBUILD_EXTMOD)),,$(@D))
> >
> > but it fails since KBUILD_EXTMOD is not evaluated path (can include
> > symlink or double slash) and @D is direct/evaluated path from *.mod
> > file.
> > -------------------------
> > the same in more details:
> > -------------------------
> >
> > In kernel Makefile the following variables are set:
> > KBUILD_EXTMOD = $M
> > MODVERDIR = $KBUILD_EXTMOD/.tmp_versions
> >
> >
> > in scripts/Makefile.modinst in lines:
> > __modules := $(sort $(shell grep -h '\.ko$$' /dev/null $(wildcard
> > $(MODVERDIR)/*.mod)))
> > modules := $(patsubst %.o,%.ko,$(wildcard $(__modules:.ko=.o)))
> >
> > The path in $MODVERDIR is evaluated correctly by shell (symbolic link
> > is followed and double slash is interpreted as single slash)
> > and the path to the module $modules is taken form $(MODVERDIR)/*.mod file).
>
>
> I tested it, but it did not happen to me.
>
> The path in $(MODVERDIR) reflects
> the directory path given via M= option for 'make modules'.
>
>
> I guess you passed a normalized path to
> 'make M=<dir> modules'
> then, a non-normalized path to
> 'make M=<dir> modules_install'
> Didn't you ?
>
>
>
> > The $modules is then passed to __modinst function as $@ where in line:
> > ext-mod-dir = $(INSTALL_MOD_DIR)$(subst $(patsubst
> > %/,%,$(KBUILD_EXTMOD)),,$(@D))
> >
> > subst function substitutes text from $KBUILD_EXTMOD to empty string in
> > directory part of $@ (@D) but here KBUILD_EXTMOD is different then @D.
> >
> >
> > Can't directory part be remove differently if using absolute paths to
> > avoid such problems ?
>
>
> I think  this is a hypothetical problem, like
>    What if a user passed different passes for
>   'make modules' and 'make modules_install' ?
>
>
>
>          $ make -C <path_to_kernel_src> M=$PWD
>
> is the idiom to build external modules.
>
> M=$PWD will do a good job for you.
>
>
> See Documentation/kbuild/modules.txt
>
>
>
>
>
> > Regards,
> >   Mikolaj Chadzynski
>
>
>
> --
> Best Regards
> Masahiro Yamada

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2018-11-12 22:47 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-08 11:26 scripts/Makefile.modinst: removing module path M from module destination is not working for some cases Mikolaj Ch
2018-11-12  5:31 ` Masahiro Yamada
2018-11-12 12:54   ` Mikolaj Ch

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.