Toshiba support in the kernel. - users - Fedora Mailing-Lists

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

1989

1988

1987

1986

1985

1984

1983

1982

1981

1980

Toshiba support in the kernel.

After installing Fedora...

akmod Nvidia dependencies

Lain Cortés González

Monday, 29 June 2015 Mon, 29 Jun '15

10:33 p.m.

So, as I'm not a hardcore developer or coder, I was wondering: Is the new support that it's dropped in the kernel for the Toshiba laptops build by default or I'd have to compile by myself from "scratch"? -Isaac C.

Reply

Show replies by date

stan

Tuesday, 30 June Tue, 30 Jun

8:30 a.m.

On Mon, 29 Jun 2015 21:33:01 -0600 Isaac Cortés González <w.isaac.cortes(a)gmail.com> wrote:

So, as I'm not a hardcore developer or coder, I was wondering: Is the new support that it's dropped in the kernel for the Toshiba laptops build by default or I'd have to compile by myself from "scratch"?

I don't use a toshiba, but I compile custom kernels, and the default configuration for the Fedora kernel in the latest version from koji, 4.2, has the following toshiba options set. Are these the options you are talking about? CONFIG_YENTA_TOSHIBA=y CONFIG_PATA_TOSHIBA=m CONFIG_MMC_TOSHIBA_PCI=m Thanks for raising the question. I'll be getting rid of them on my next iteration, since they're just wasted bits for me. :-) That's the hard part of compiling a custom kernel; eliminating all the irrelevant modules and functionality. I've looked, and there doesn't seem to be a program that scans the system, and only turns on hardware modules for the system scanned. I'm surprised, actually. And I'm thinking of hacking together something in python that uses lspci and lsmod and /proc to turn off all the drivers I don't need in the .config file.

Reply

Heinz Diehl

9:24 a.m.

On 30.06.2015, stan wrote:

That's the hard part of compiling a custom kernel; eliminating all the irrelevant modules and functionality. I've looked, and there doesn't seem to be a program that scans the system, and only turns on hardware modules for the system scanned.

"make localmodconfig" is what you're after. Be aware that localmodconfig does exactly what you want. So if you e.g. don't have connected a device containing an ext4 filesystem at the moment you issue the command, ext4 support won't be in your new kernel.

Reply

stan

11:07 a.m.

On Tue, 30 Jun 2015 16:24:56 +0200 Heinz Diehl <htd+ml(a)fritha.org> wrote:

On 30.06.2015, stan wrote: > That's the hard part of compiling a custom kernel; eliminating all > the irrelevant modules and functionality. I've looked, and there > doesn't seem to be a program that scans the system, and only turns > on hardware modules for the system scanned. "make localmodconfig" is what you're after. Be aware that localmodconfig does exactly what you want. So if you e.g. don't have connected a device containing an ext4 filesystem at the moment you issue the command, ext4 support won't be in your new kernel.

Whoa! Thank you! This could be a game changer. Yeah, it's a little risky, but my system is very stable, and I only compile kernels when everything is attached and running smoothly. I'm surprised this wasn't mentioned in the build instructions at kernel.org. Or maybe I just missed it. Now I've got to rush off and compile a new kernel. :-)

Reply

Chris Murphy

12:20 p.m.

On Tue, Jun 30, 2015 at 8:24 AM, Heinz Diehl <htd+ml(a)fritha.org> wrote:

On 30.06.2015, stan wrote: > That's the hard part of compiling a custom kernel; eliminating all the > irrelevant modules and functionality. I've looked, and there doesn't > seem to be a program that scans the system, and only turns on hardware > modules for the system scanned. "make localmodconfig" is what you're after. Be aware that localmodconfig does exactly what you want. So if you e.g. don't have connected a device containing an ext4 filesystem at the moment you issue the command, ext4 support won't be in your new kernel.

Does localmodconfig set drivers to n such that they aren't even compiled? Or are they m such that they are modules that are only loaded on demand? I'm going to guess the answer is n, the point of which is it saves a ton of compile time, not so much creating a lean kernel (as anything not needed wouldn't be loaded anyway). Correct? -- Chris Murphy

Reply

stan

1:43 p.m.

On Tue, 30 Jun 2015 11:20:36 -0600 Chris Murphy <lists(a)colorremedies.com> wrote:

On Tue, Jun 30, 2015 at 8:24 AM, Heinz Diehl <htd+ml(a)fritha.org> wrote: > On 30.06.2015, stan wrote: > >> That's the hard part of compiling a custom kernel; eliminating all >> the irrelevant modules and functionality. I've looked, and there >> doesn't seem to be a program that scans the system, and only turns >> on hardware modules for the system scanned. > > "make localmodconfig" is what you're after. Be aware that > localmodconfig does exactly what you want. So if you e.g. don't have > connected a device containing an ext4 filesystem at the moment you > issue the command, ext4 support won't be in your new kernel. Does localmodconfig set drivers to n such that they aren't even compiled? Or are they m such that they are modules that are only loaded on demand? I'm going to guess the answer is n, the point of which is it saves a ton of compile time, not so much creating a lean kernel (as anything not needed wouldn't be loaded anyway). Correct?

I just compiled a kernel using localmodconfig, and you are exactly right. It set all the modules I didn't need to n, and the kernel compiled a lot more quickly than usual. The size of the kernel was just slightly smaller than previously. It used the configuration of the running kernel as a starting point, so I didn't lose all the other customization I had implemented over the iterations. I'm just about to boot into the new kernel, so the proof of the pudding will soon be apparent. If it boots, as it should, I'll be pleased with this way of building kernels.

Reply

Chris Murphy

1:51 p.m.

Just as an FYI for those who may not know this, but the Fedora Project has build servers almost constantly building new kernels. You can go to koji.fedoraproject.org and type in kernel in the package field. Or go to URL http://koji.fedoraproject.org/koji/packageinfo?packageID=8 For example today's built kernels already are: kernel-4.0.7-300.fc22 kernel-4.0.7-200.fc21 And for the bleeding edgers, yesterday's build was: kernel-4.2.0-0.rc0.git2.1.fc23 For the uninitiated, be aware the git kernels often have kernel debugging enabled and will run slower. Typically the first (U.S.) work day after a kernel release, there will be non-debug and debug kernels listed; but when a debug kernel is not listed that means all of those builds are debug kernels. So it's possible to completely avoid building kernels if you don't have special customizations you need done, and yet get very recent kernel versions. Chris Murphy -- Chris Murphy

Reply

stan

1:48 p.m.

On Tue, 30 Jun 2015 11:20:36 -0600 Chris Murphy <lists(a)colorremedies.com> wrote:

Does localmodconfig set drivers to n such that they aren't even compiled? Or are they m such that they are modules that are only loaded on demand? I'm going to guess the answer is n, the point of which is it saves a ton of compile time, not so much creating a lean kernel (as anything not needed wouldn't be loaded anyway). Correct?

The new kernel compiled with localmodconfig is running just fine.

Reply

stan

1:52 p.m.

On Tue, 30 Jun 2015 11:20:36 -0600 Chris Murphy <lists(a)colorremedies.com> wrote:

Does localmodconfig set drivers to n such that they aren't even compiled? Or are they m such that they are modules that are only loaded on demand? I'm going to guess the answer is n, the point of which is it saves a ton of compile time, not so much creating a lean kernel (as anything not needed wouldn't be loaded anyway). Correct?

The other thing I noticed that was different from my former compiles, is that this one didn't generate a new perf or python-perf.

Reply

3232

days inactive

3232

days old

users@lists.fedoraproject.org

Manage subscription

8 comments

4 participants

tags (0)

participants (4)

Chris Murphy
Heinz Diehl
Lain Cortés González
stan