Trouble Installing Compiled Kernel
Hi, I recently decided to try and make contributions to the kernel. I normally just use windows as my operating system so I decided to set up Slackware to develop on. I thought a good place to start would to actually compile the kernel and install it before I actually make any changes. I ran: make O=/home/nathanael/KernelBuild localmodconfig make O=/home/nathanael/KernelBuild After getting it compiled I ran: bash-4.3$ sudo make O=/home/nathanael/KernelBuild/ install_module install but got this error: make[1]: Entering directory '/home/nathanael/KernelBuild' make[1]: *** No rule to make target 'install_module'. Stop. make[1]: Leaving directory '/home/nathanael/KernelBuild' Makefile:180: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 I have tried looking around but haven't found anything that has been particularly useful in figuring this out. I am not sure what info might be relevant so I'll just let you know that I'm on Slackware 14.2 and trying to upgrade the Kernel from 4.4.208 to 5.6.0 and I am using ELILO instead of LILO. If anyone has any suggestions or can even just direct me to some resources that might have more info on what is going on with make install_module or the error that would be sick. Thanks.___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Trouble Installing Compiled Kernel
Hey, I think you want modules_install instead of install_module -Marcelo On Wed, Mar 25, 2020 at 12:23 PM Nathanael J Grix wrote: > > Hi, > I recently decided to try and make contributions to the kernel. I normally > just use windows as my operating system so I decided to set up Slackware to > develop on. I thought a good place to start would to actually compile the > kernel and install it before I actually make any changes. I ran: > make O=/home/nathanael/KernelBuild localmodconfig > make O=/home/nathanael/KernelBuild > > After getting it compiled I ran: > bash-4.3$ sudo make O=/home/nathanael/KernelBuild/ install_module install > > but got this error: > make[1]: Entering directory '/home/nathanael/KernelBuild' > make[1]: *** No rule to make target 'install_module'. Stop. > make[1]: Leaving directory '/home/nathanael/KernelBuild' > Makefile:180: recipe for target 'sub-make' failed > make: *** [sub-make] Error 2 > > I have tried looking around but haven't found anything that has been > particularly useful in figuring this out. I am not sure what info might be > relevant so I'll just let you know that I'm on Slackware 14.2 and trying to > upgrade the Kernel from 4.4.208 to 5.6.0 and I am using ELILO instead of > LILO. If anyone has any suggestions or can even just direct me to some > resources that might have more info on what is going on with make > install_module or the error that would be sick. Thanks. > ___ > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Trouble Installing Compiled Kernel
On Wednesday, March 25, 2020 12:38 PM, Valentin Vidić wrote: > On Wed, Mar 25, 2020 at 04:22:47PM +, Nathanael J Grix wrote: > > > After getting it compiled I ran: > > bash-4.3$ sudo make O=/home/nathanael/KernelBuild/ install_module install > > This should be modules_install. > > -- > > Valentin > > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Sorry, that was just a typo I believe that I used modules_install and not install_module. I ran it again with modules_install just to be sure and still got the same error message: bash-4.3$ make O=/home/nathanael/Kernel-5.6.0/ install_modules install make[1]: Entering directory '/home/nathanael/Kernel-5.6.0' make[1]: *** No rule to make target 'install_modules'. Stop. make[1]: Leaving directory '/home/nathanael/Kernel-5.6.0' Makefile:180: recipe for target 'sub-make' failed make: *** [sub-make] Error 2 If you have any other suggestions or resources that would be much appreciated. Thanks. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Trouble Installing Compiled Kernel
On Wednesday, March 25, 2020 12:38 PM, Valentin Vidić wrote: > On Wed, Mar 25, 2020 at 04:22:47PM +, Nathanael J Grix wrote: > > > After getting it compiled I ran: > > bash-4.3$ sudo make O=/home/nathanael/KernelBuild/ install_module install > > This should be modules_install. > > -- > > Valentin > > Kernelnewbies mailing list > Kernelnewbies@kernelnewbies.org > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies After reviewing your email again I realized that I'm a idiot. Rere-ran it but this time with the words in the correct order and it worked. Thank you for your help. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Trouble Installing Compiled Kernel
On Wed, Mar 25, 2020 at 04:22:47PM +, Nathanael J Grix wrote: > After getting it compiled I ran: > bash-4.3$ sudo make O=/home/nathanael/KernelBuild/ install_module install This should be modules_install. -- Valentin ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: linux kernel coding style and checkpatch.pl script
On Wed, 25 Mar 2020 10:36:08 +0100, Tomek The Messenger said:
> There is checkpatch.pl script
To borrow from Pirates of the Carribean, "They're not exactly rules, they're
more like... suggestions..."
Checkpatch flags *possible* code style problems, but it's not perfect. There's
often good reason to ignore them. For example:
> However can I ignore warning message?
> WARNING: quoted string split across lines
> #974: FILE: fpgax67-core.c:974:
> + dev_err(>dev, "registration not done, driver is already
> "
> + "registered\n");
>
> If I don't split line I will have another warning that 80 characters is
> exceeded.
Blech. Ick.
Don't split literal strings, it means that grepping the source tree for
"already registered" fails. Making grep for a string work is more important
than shutting up checkpatch.
> For sure I can ignore warnings about:
> WARNING: struct should normally be const
> #998: FILE: fpgax67-core.c :998:
This one you actually need to look at what the routine says. The object is
*usually* a const - but might not be. Figure out what it actually does.
Always keep in mind that it's a perl script, and just doing regex matching. It
has no clue what the code actually does. Hopefully you have more understanding
of the code than the perl script does...
> For sure all errors must be fixed like:
> const char* tmp -> change to -> const char *tmp;
> if(� => if (� �#insert space
If this is new code you're writing, you should fix it before you submit the
patch adding the code. (Unless of course, checkpatch is wrong about a
variable needing to be a const, or similar)
If you're doing major changes to existing code anyhow, a cleanup patch first is
often appropriate.
If you're just fixing checkpatch warnings for the sake of fixing checkpatch
warnings, keep in mind that many maintainers won't accept patches that just
clean up checkpatch, for several reasons:
First, if it's code that's been static for a while (years, sometimes), there's
always a danger that a patch breaks something. No reason to touch stable code.
If it's code that somebody else is working on, your patch can cause merge
errors with the other person's (which is why only the person doing the other
work should do cleanup patches - they won't conflict with their own work).
Also, it messes up the git history - consider a patch that changes
an 'if( foo && !bar) {' to 'if( foo && !baz){' to fix a bug where the wrong
variable was being tested. You then submit a patch to fix the space.
Now a 'git blame' on the file shows your patch rather than the one that
fixes the bug.
However, I have it on good authority that Greg KH will cheerfully accept
checkpatch fixes for anything under 'drivers/staging', because that code
is usually in such bad shape that fixups are needed. :)
Personally, I do kernel builds with sparse and extra gcc warnings, and submit
patches only after applying some thought and concluding things like "Yes,
sparse and/or gcc were correct, the variable *should* be static so it can't be
accessed from another module due to a namespace collision".
In other words, the patch should *never* be "Fix a checkpatch/sparse/gcc
complaint". It should always be "Make an objective improvement to the code
that happened to be pointed out by static analysis tools".
pgpTgKdzF3KBZ.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Finding bugs/issues to work on
On Tue, 24 Mar 2020 16:49:29 +0530, Suraj Upadhyay said: > Hii newbies, > I just started studying for linux-kernel development although I am > not completely new to open source technologies. I wanted to clarify my > doubts in the following things > 1. Where can I find issues/tickets regarding linux-kernel, to work on ? > 2. What's the best resource to get started on linux-kernel development ? > I started reading kernel-newbies guides, though. Can we configure the list to send a greeting message with intro material when somebody subscribes to the list? In the meantime, I'll repeat myself here... https://lists.kernelnewbies.org/pipermail/kernelnewbies/2017-April/017765.html pgpJA1w4Tty03.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
linux kernel coding style and checkpatch.pl script
Hi There is checkpatch.pl script where You can check if You wrote code in your kernel module according to linux kernel style. However can I ignore warning message? WARNING: quoted string split across lines #974: FILE: fpgax67-core.c:974: + dev_err(>dev, "registration not done, driver is already " + "registered\n"); If I don't split line I will have another warning that 80 characters is exceeded. For sure I can ignore warnings about: WARNING: struct should normally be const #998: FILE: fpgax67-core.c :998: +int fpgax67_unregister(struct platform_device *pdev) For sure all errors must be fixed like: const char* tmp -> change to -> const char *tmp; if( => if ( #insert space Generally I don't know how much warnings should I correct. If it is mandatory or only good practise and I can omit some if it doesn't make sense. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: linux kernel coding style and checkpatch.pl script
On Wed, Mar 25, 2020 at 10:36:08AM +0100, Tomek The Messenger wrote: > Hi > There is checkpatch.pl script where You can check if You wrote code in your > kernel module according to linux kernel style. > However can I ignore warning message? > WARNING: quoted string split across lines > #974: FILE: fpgax67-core.c:974: > + dev_err(>dev, "registration not done, driver is > already " > + "registered\n"); > > If I don't split line I will have another warning that 80 characters is > exceeded. No you should not. > For sure I can ignore warnings about: > WARNING: struct should normally be const > #998: FILE: fpgax67-core.c :998: > +int fpgax67_unregister(struct platform_device *pdev) No, please do not. > For sure all errors must be fixed like: > const char* tmp -> change to -> const char *tmp; > if( => if ( #insert space Yes. > Generally I don't know how much warnings should I correct. If it is > mandatory or only good practise and I can omit some if it doesn't make > sense. If you want your code merged properly, and reviewed, just fix them all, should not take more than a few hours. good luck! greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
