Author Topic: Kernel configuration  (Read 4909 times)

Offline Tokka

  • Developer
  • Full Member
  • ***
  • Posts: 193
  • Karma: +16/-0
    • View Profile
Kernel configuration
« on: January 27, 2014, 03:42:46 pm »
A good point of start, imho, may be the build of a working "universal" kernel, more complete as possible, and more light...as possible.
Who is interested, should download the necessary packages to compile the kernel, and we can choice what include and what exclude, what create conflict, etc etc.
What's your opinion?
CB1 (A10) - Qbee-X_TMC

Offline Jojo

  • Developer
  • Full Member
  • ***
  • Posts: 190
  • Karma: +13/-0
  • Cubieboard 2 - A20, aRUNTU v1.666
    • View Profile
Re: Kernel configuration
« Reply #1 on: January 27, 2014, 04:39:53 pm »
Hi,

well, for me it sounds good. Although I don't really know what that means in detail. If that means things like drivers and modules, I would say lets have a look at that what folks do with the boards. They use USB bluetooth and wifi dongles, maybe USB sound cards, keyboards, mouses (wired and wireless). SATA HDDs and other drives (DVD, maybe BR)
People want to use GPIOs, IR, CPU features (clock scaling, 3d and 2d acceleration, etc.).

Did you already recognize any problems or conflicts with the .75 kernel from patwood? Or do you mean things like additional software packages, too? Sorry for the questions... I am the noob  ;D  ::) ...

Greetings
Don't think that anyone will take more pains for his answer, as you took for your question.

Offline Jojo

  • Developer
  • Full Member
  • ***
  • Posts: 190
  • Karma: +13/-0
  • Cubieboard 2 - A20, aRUNTU v1.666
    • View Profile
Re: Kernel configuration
« Reply #2 on: January 27, 2014, 04:57:32 pm »
No "Edit" functionality  :o ...

For GPIO things, special functions like SPI, UARTs, I2C, PWM, 1-Wire... should be supported.
Don't think that anyone will take more pains for his answer, as you took for your question.

Offline Tokka

  • Developer
  • Full Member
  • ***
  • Posts: 193
  • Karma: +16/-0
    • View Profile
Re: Kernel configuration
« Reply #3 on: January 28, 2014, 11:40:17 am »
More or less i mean to include all possible drivers and modules to cover 360° peoples needs, but not all modules in the kernel config are needed, someone is deprecated. And a simple how-to to make a module if it not present in the kernel, to complete it.
CB1 (A10) - Qbee-X_TMC

Offline Jojo

  • Developer
  • Full Member
  • ***
  • Posts: 190
  • Karma: +13/-0
  • Cubieboard 2 - A20, aRUNTU v1.666
    • View Profile
Re: Kernel configuration
« Reply #4 on: January 30, 2014, 05:01:01 pm »
Hello,
 ok, sounds good :) . But... where will be the difference to the actual releases by patwood? His releases support most hardware and most modules are included, too (I only really dont know what all these parameters for accelerometer, gyroscope, ect are for  ???).
How do you want to improve these things? The way how users can add/remove modules and drivers? Or are you planning to make everything working out of the box?

Greetings
Don't think that anyone will take more pains for his answer, as you took for your question.

Offline Tokka

  • Developer
  • Full Member
  • ***
  • Posts: 193
  • Karma: +16/-0
    • View Profile
Re: Kernel configuration
« Reply #5 on: January 30, 2014, 05:11:22 pm »
Not much differences, Pat's kernel is almost complete. It's overall to have a base for future kernels, as start point.
I don't know the use of a great part of kernels modules/drivers, so i don't know if they really are needed or not.
And doing a "standard" config, every users may customize it as want, to make a proper (slim...or heavy  :o) kernel.

Something like: i need a kernel with xxx, yyy, zzz...so take the "standard", than add..add..add...add..., or remove...remove....remove...remove....
It may be used as base for sunxi git too, to have a premade fully working kernel  ;D
Cheers
CB1 (A10) - Qbee-X_TMC

Offline patwood

  • Linux geek
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1660
  • Karma: +129/-0
    • View Profile
Re: Kernel configuration
« Reply #6 on: January 31, 2014, 01:44:29 am »
Not much differences, Pat's kernel is almost complete. It's overall to have a base for future kernels, as start point.
I don't know the use of a great part of kernels modules/drivers, so i don't know if they really are needed or not.
And doing a "standard" config, every users may customize it as want, to make a proper (slim...or heavy  :o) kernel.

Something like: i need a kernel with xxx, yyy, zzz...so take the "standard", than add..add..add...add..., or remove...remove....remove...remove....
It may be used as base for sunxi git too, to have a premade fully working kernel  ;D
Cheers

Thanks.

Adding lots of modules (not compiled into the kernel, but loadable with modprobe) can work well, as the current set is running around 40MB, and turning on a whole bunch more would probably add 10MB or so.  Anyone can remove modules from /lib/modules/<kernel-version> if they don't need some and want to reduce the kernel's size.  Rerunning depmod once after removing some modules shouldn't be a big deal, as long as this is part of the documented process.

Another option is to have a "standard" kernel with some reasonable subset of loadable modules in /lib/modules, and one or more "packages" of companion modules that can be added by copying them to /lib/modules/<kernel-version> and running depmod.  If we're talking about saving perhaps 20MB or so of space on a 4GB SD card or NAND, that's what? 1/2%?  Personally, I'd prefer to provide support for everything possible and let people who are really short of storage space trim the files, rather than make people "install" drivers that they need.

Adding modules inside the kernel increases its size and its memory consumption. Lots of embedded linuxes out there have kernels ~1/2 the size of the ones I'm currently building.  I don't think the kernel should grow much beyond where it's at now, but saving 2-3MB of NAND/SD space and RAM by moving modules out into /lib/modules doesn't really pay back very much for us right now.  There are a few 512MB cubieboards floating around (somewhere), but even then we're talking about (possibly) saving ~1/2% on the DRAM space and losing boot-time support for anything that's moved out of the kernel (e.g., move SATA out of the kernel to a loadable module, and you can't use a SATA drive as a root FS without creating a special initrd; same for moving various file systems out, or USB storage, etc).

This is a good conversation to have, and I'm happy to help out and continue building kernels for A10 and A20.

Offline patwood

  • Linux geek
  • Global Moderator
  • Hero Member
  • *****
  • Posts: 1660
  • Karma: +129/-0
    • View Profile
Re: Kernel configuration
« Reply #7 on: January 31, 2014, 01:53:02 am »
Oh, and as long as I'm thinking about this, testing is a very important issue.  People ask me to add new modules; some I can test, most I can't.  Any spreadsheet of supported modules should also note their status -- in general use with no known problems (emac, gmac, USB storage, etc), tested by one or two people (and who tested it and under what conditions), tested but with known problems (USB gadget and CT bluetooth come to mind), or untested.

There may be additional states -- tested on A10 but not A20, tested on CT but not CB2, etc.

Offline Tokka

  • Developer
  • Full Member
  • ***
  • Posts: 193
  • Karma: +16/-0
    • View Profile
Re: Kernel configuration
« Reply #8 on: January 31, 2014, 03:21:25 am »
I agree, 1/2% of space is not enought, and is more the work than the gain...
But if the "community" make some test (as you said) giving you feedback, this may keep your works fast and thin as possible...
In other words...you help us developing kernel, we help you with test and feed.
I think this is the community spirit :P

ps: in a couple of week i would try to test kernel 3.10, you'r advised  ;D ;D ;D
CB1 (A10) - Qbee-X_TMC

Offline Jojo

  • Developer
  • Full Member
  • ***
  • Posts: 190
  • Karma: +13/-0
  • Cubieboard 2 - A20, aRUNTU v1.666
    • View Profile
Re: Kernel configuration
« Reply #9 on: January 31, 2014, 06:13:38 am »
Hello,

for me, I like it as it is at the moment. The modules are there and can be loaded or unloaded by the user. Of couse, I agree that the OS should be kept as light and fast as possible. But on the other hand the features of our boards must be supported.
So I would say something like "As light as possible, but as heavy as neccessary.:D .

Greetings!
Don't think that anyone will take more pains for his answer, as you took for your question.