linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bryan Brattlof <hello@bryanbrattlof.com>
To: Krish Jain <krishjain02939@gmail.com>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	linux-staging@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Declare the file_operations struct as const
Date: Sun, 29 Aug 2021 21:00:02 +0000	[thread overview]
Message-ID: <20210829205953.63ebc32xlyudsqzg@h510> (raw)
In-Reply-To: <CAPGkw+xroJmxa9i6X++un6tQFQ-3F5uMRCatzufWsdfw7cQ2LQ@mail.gmail.com>

On this day, August 29, 2021, thus sayeth Krish Jain:
> Keeping you updated. Small win. The "Symbol version dump
> "Module.symvers" is missing. " error disappeared. Now I still don't
> know why
>

Whoop! Any win, no matter their size, always feel great. I ran around
the house yesterday after cross compiling DOOM! for an armel chip. It's
that "win" feeling you get that keeps me involved.

It is important that you find out why though. What is the importance to
having Module.symvers? and why is it a WARNING and not an ERROR?

What would happen if we didn't have the proper symbols when compiling or
installing this driver?

How and what generates the Module.symvers file when we *do* need it?

How can we turn this warning off when we don't need it?

This is covered in chapter "6. Module Versioning"

  https://www.kernel.org/doc/html/latest/kbuild/modules.html

>
> ERROR: Kernel configuration is invalid."; \
> echo >&2 "         include/generated/autoconf.h or
> include/config/auto.conf are missing.";\
> echo >&2 "         Run 'make oldconfig && make prepare' on kernel src
> to fix it."; \
>
>
> is still present.
>
> How can I fix this?
>

Are there any other 'make *config' options we could try?

What does 'make prepare' even do?

Why do we even need a configuration file?

  https://www.kernel.org/doc/html/latest/kbuild/kconfig.html

>
> Best Regards
>
> On Sun, Aug 29, 2021 at 8:28 PM Krish Jain <krishjain02939@gmail.com> wrote:
> >
> > Basically it says "you must have a prebuilt kernel available that
> > contains the configuration and header files used in the build." Since
> > for the staging kernel  "make oldconfig" asked me for  more
> > configurations apart from my old configuration file (as it reads the
> > existing .config file that was used for an old kernel and prompts the
> > user for options in the current kernel source that are not found in
> > the file) . So I *don't* currently have a prebuilt kernel that
> > contains all the configuration in my staging kernel's .config file. So
> > do I have to build the kernel once before I can just build the module
> > with "make CCFLAGS=-Werror W=1 M=drivers/staging/android" ?
> >

What do all these other configuration settings turn on and off anyway?

Do we really need CONFIG_INFINIBAND turned on if we're working in the
drivers/staging tree of the kernel?

What would we gain from having a compiled kernel if we want to test a
single staging driver?

If you found what Module.symvers does, you should know this.

> > > >
> > > > Again, do not allow others to rob you of learning how to solve these
> > > > issues yourself. I *strongly* encourage you to familiarize yourself with
> > > > the Kernel Build System in the Documentation.
> > > >
> > > >   https://www.kernel.org/doc/html/latest/kbuild/modules.html
> > > >
> > > > Specifically the first paragraph of "2. How to Build External Modules"
> > > >
> > > > It may seem like a lot for such a simple issue but it *is* worth it.
> > > > ~Bryan
> > > >
> > >
> > > That section says
> > >
> > >
> > > "To build external modules, *you must have a prebuilt kernel
> > > available* that contains the configuration and header files used in
> > > the build. Also, the kernel must have been built with modules enabled.
> > > If you are using a distribution kernel, there will be a package for
> > > the kernel you are running provided by your distribution.
> > >
> > > An alternative is to use the “make” target “modules_prepare.” This
> > > will make sure the kernel contains the information required. The
> > > target exists solely as a simple way to prepare a kernel source tree
> > > for building external modules.
> > >
> > > NOTE: “modules_prepare” will not build Module.symvers even if
> > > CONFIG_MODVERSIONS is set; therefore, *a full kernel build needs to be
> > > executed to make module versioning work.*"
> > >
> > > So I am just trying to confirm with you whether I have to first build
> > > the kernel with like "make" or not? As you can imagine my hardware
> > > takes *very* long to build a kernel as I did in my last attempt so I
> > > am asking whether it is needed. Hope you understand.
> > >

I understand. Though I still don't wish to rob you of this opportunity.

Your ability to come up with these questions and answer them yourself is
what will make you a better programmer and developer.

Don't get me wrong. Greg knows all too well the garbage I can shovel his
way. It's not about knowing the answer. It about knowing how to find the
answer yourself.

~Bryan


  reply	other threads:[~2021-08-29 21:00 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-29 14:45 [PATCH] Declare the file_operations struct as const Bryan Brattlof
2021-08-29 16:20 ` Krish Jain
2021-08-29 16:34   ` Krish Jain
2021-08-29 16:49   ` Bryan Brattlof
2021-08-29 16:56     ` Krish Jain
2021-08-29 18:28       ` Krish Jain
2021-08-29 18:46         ` Krish Jain
2021-08-29 21:00           ` Bryan Brattlof [this message]
2021-08-29 22:11             ` Krish Jain
2021-08-30 12:40               ` Krish Jain
2021-08-30 13:01                 ` Krish Jain
2021-08-31  0:42                   ` Krish Jain
2021-08-31 13:35                     ` Bryan Brattlof
2021-08-31 14:00                       ` Fabio M. De Francesco
2021-08-31 23:00                         ` Bryan Brattlof
2021-09-01 15:20                           ` Krish Jain
2021-09-01 15:30                             ` Greg KH
2021-09-01 15:34                               ` Krish Jain
2021-09-01 16:51                                 ` Greg KH
2021-09-01 17:34                                   ` Bryan Brattlof
2021-09-01 18:04                                     ` Krish Jain
2021-09-01 20:29                                       ` Bryan Brattlof
     [not found] <CAPGkw+x+B1731SL=afoSKiWwH-n-FA5YJ+WOwYdv8iyFhWk1zA@mail.gmail.com>
     [not found] ` <3634721.RBzQ2xsved@localhost.localdomain>
2021-08-27  7:48   ` Fabio M. De Francesco
2021-08-27  8:50     ` Krish Jain
2021-08-27 18:38       ` Krish Jain
2021-08-27 19:46         ` Krish Jain
2021-08-27 23:38           ` Bryan Brattlof
2021-08-28  9:37             ` Krish Jain
2021-08-28  9:46               ` Greg KH
2021-08-28  9:52                 ` Krish Jain
2021-08-28 11:13                   ` Fabio M. De Francesco
2021-08-29  2:13             ` Krish Jain
2021-08-29  2:16               ` Krish Jain
2021-08-29  6:16               ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2021-08-27  2:19 Krish Jain

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=20210829205953.63ebc32xlyudsqzg@h510 \
    --to=hello@bryanbrattlof.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=krishjain02939@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).