[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKi4VAKL4B3cLZN5afyeTMaZ49z2eRXcnBRtNi+0so0G8m5dYQ@mail.gmail.com>
Date: Tue, 24 Feb 2015 22:07:22 -0300
From: Lucas De Marchi <lucas.de.marchi@...il.com>
To: Harish Jenny Kandiga Nagaraj <harish_kandiga@...tor.com>
Cc: Michal Marek <mmarek@...e.cz>,
Rusty Russell <rusty@...tcorp.com.au>,
linux-modules <linux-modules@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
greg KH <gregkh@...uxfoundation.org>
Subject: Re: Differences between builtins and modules
On Tue, Feb 24, 2015 at 8:42 AM, Harish Jenny Kandiga Nagaraj
<harish_kandiga@...tor.com> wrote:
>
> On Monday 23 February 2015 09:21 PM, Michal Marek wrote:
>> On 2015-02-23 15:30, Lucas De Marchi wrote:
> Can we add some flag like
> KMOD_PROBE_FORCE_DIRECTORY_CHECK = 0x00040,
> and pass it to kmod_module_get_initstate to make
> "modprobe --show-depends vt" to report as "builtin" ?
I don't want to add more flags. It's already pretty complicated, more
than it should IMO. If the tools using kmod can live with the change
proposed here, I'm ok with that.
> Also if the use case for loading builtin modules is not that common
> ( Also don’t know if 'modprobe vt' command does the loading if not loaded)
> can we have the same flags be used after checking if it is .ko file or from .o file if required?
Well... there's no way for us to arrive at the final call to
finit_module() for a builtin module. Simply because there's no file to
load in memory (or fd to open) to pass to these functions. We simply
fail because we can't reach that far in the code.
--
Lucas De Marchi
--
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/
Powered by blists - more mailing lists