# The new idea of creating a linux kernel!

## Serj

How will you like to create linux kernel like emerge packages in portage? 

I.e. you type somthing like:

```
KERNELPROFILE="gentoo" emerge kernel-2.6.7
```

and then portage merge new kernel in your system with all "gentoo" patches. Or you type this:

```
KERNELPROFILE="love" emerge kernel-2.6.7
```

and portage create for you your lovely love sources.  :Smile: 

We can place kernel profiles in /etc/kernel for example and name it like "gentoo.profile", "love.profile", "xx.profile", "my.profile", etc. In this files we will need to place a list of patches (or/and rules of applying it) that we want to see in our kernel.

This method of creating a kernel will avoid need of creating custom ebuild for custom kernel.

So, what do you say about it? Do you like this idea and it is posible to realize it?

P.S. Sorry for my English!   :Embarassed: 

----------

## dec

I quite like this idea... it would be a lot neater than all the random *-sources in portage, and would make upgrading etc easier.

If you were to take it further, you could have the 'kernel profiles' as a list of the patches to be applied to the vanilla kernel? This would mean people could customise the patched kernels a lot easier.

Just an idea... any thoughts?

----------

## smart

sounds good for its possibilities. i'd suggest it to be an additional kernel, though, just to make an evolution instead of revolution. so you could make this like a new kernelpackage, e.g. being called by

emerge profiled-kernel

----------

## Serj

 *smart wrote:*   

> so you could make this like a new kernelpackage, e.g. being called by emerge profiled-kernel

 

I can't do this because i am a simple user not a guru!  :Wink: 

I will be happy if anybody can do this...

----------

## ett_gramse_nap

I really like the idea!

----------

## nmcsween

It's a bad idea why because people would start throwing patches together left and right and ask "whats a failed hunk?" just creating more problems for developers. I think kernels should be left to the amount of  knowledge someone has.

----------

## Serj

 *nmcsween wrote:*   

> It's a bad idea why because people would start throwing patches together left and right and ask "whats a failed hunk?" just creating more problems for developers.

 

I don't think so. This people must use "official" profiles. And developers must support only "official" profiles.

But if users want to use something special they must use it on your own risk!

In general, supporter don't answer for the consequences if the user edit wrong config file for some package.

----------

## smart

 *Quote:*   

> 
> 
> It's a bad idea why because people would start throwing patches together left and right and ask "whats a failed hunk?" just creating more problems for developers.
> 
> 

 

I would expect it to create less. Why ? I would over time drop almost all kernel packages from portage. You'd possibly stick with vanilla, gentoo and some architecture specific like sparc, mips et al.

Anything else you would leave to the profiles. And you would not support profiles from a developers side at all. You would ensure that the processing of profiles is correct, no more no less. It's not that developers take support responsibility for the correct setup of ones /etc/conf.d/net files or /etc/make.conf. They ensure that the settings are interpreted correctly, not that they are correct. That's what profiles would be like. And users had to ensure their validity themselves.

----------

## Serj

I think kernel profiles must be place in this hierarchy:

```
/etc/kernel/arch/kernel-version
```

for example:

```
/etc/kernel/x86/2.6.7
```

And this profiles must be part of ebuild scripts (writing in the same language).

So, can anybody offer this idea to official gentoo maintainers?

----------

## smart

Yes, you :]

but i would not suggest it to be a prgram (as in same as ebuild) but simply a list of patches to apply to the kernel sources, plus possibly their source for  download, so that emerge could fetch and apply them in the order given. No programming magic in between.

----------

## oberyno

Hi there.

This is an interesting idea you have, but it has some problems. For example: What if a user likes Andrea Arcangeli's kernel? To get the most recent kernel they might do 

```
KERNELPROFILE="aa" emerge kernel-2.6.7
```

The problem is Andrea's patches are for 2.6.5. So, if it went ahead and actually tried to build and patch the kernel, quite a few hunks would fail. It would instead have to tell you to use 2.6.5. Emerge handles this scenario fine right now.

As for  *dec wrote:*   

> I quite like this idea... it would be a lot neater than all the random *-sources in portage, and would make upgrading etc easier.
> 
> 

 

Instead of having lots of sources in /usr/portage/sys-kernel you would have lots of profiles in /etc/kernels. Is that really making upgrading easier?

The place where this idea might be useful IMHO, is for emerging old kernels. Something like:

```
KERNELPROFILE="mm" emerge kernel-2.6.3
```

Portage doesn't really have room for every version of every kernel. That being said, I don't think it's a feature that alot of people want. I haven't heard anybody complain that old mm-sources aren't in portage anymore.

And also, how would this handle different releases, like gentoo-dev-sources-2.6.7-r8 or r9?

----------

## Serj

 *oberyno wrote:*   

> What if a user likes Andrea Arcangeli's kernel? To get the most recent kernel they might do 
> 
> ```
> KERNELPROFILE="aa" emerge kernel-2.6.7
> ```
> ...

 

If there is an aa-patch for 2.6.7 it's posible to install kernel 2.6.7 with this patch. If isn't - then it is not possible.

 *oberyno wrote:*   

> Instead of having lots of sources in /usr/portage/sys-kernel you would have lots of profiles in /etc/kernels. Is that really making upgrading easier?

 

It will make INSTALLATION of custom kernel very simple - just create a profile and emerge kernel!

 *oberyno wrote:*   

> The place where this idea might be useful IMHO, is for emerging old kernels. Something like:
> 
> ```
> KERNELPROFILE="mm" emerge kernel-2.6.3
> ```
> ...

 

Kernel maintainers would place some official kernel profiles in foders "files" of kernel folders in the Portage. Then we will emerge kernel this profiles will be copied to /etc/kernel/[arch]/[kernel ebuild version]. Then needed patch will be applayed to kernel source.

If we want to create custom kernel we just place custom profile in /etc/kernel/[arch]/[kernel ebuild version] and then emerge kernel. Emerge must unapply previous patches and apply current. Very simple!

```

Examples:

Kernel package folder in Portage:

./linux-kernel

./linux-kernel/linux-2.6.3-r3.ebuild

./linux-kernel/linux-2.6.7.ebuild

...

./linux-kernel/files

./linux-kernel/files/x86/2.6.3-r3/gentoo.profile

./linux-kernel/files/x86/2.6.3-r3/aa.profile

./linux-kernel/files/x86/2.6.3-r3/mm.profile

...

./linux-kernel/files/x86/2.6.7/gentoo.profile

./linux-kernel/files/x86/2.6.7/mm.profile

...

/etc/kernel folder:

/etc/kernel

/etc/kernel/x86/2.6.3-r3/gentoo.profile

/etc/kernel/x86/2.6.3-r3/aa.profile

/etc/kernel/x86/2.6.3-r3/mm.profile

/etc/kernel/x86/2.6.3-r3/love.profile

/etc/kernel/x86/2.6.3-r3/my.profile

...

/etc/kernel/x86/2.6.7/gentoo.profile

/etc/kernel/x86/2.6.7/mm.profile

/etc/kernel/x86/2.6.7/love.profile

/etc/kernel/x86/2.6.7/my.profile

```

P.S. Sorry for my English again.  :Embarassed: 

----------

## DiskBreaker

I must say I really like this idea, too   :Cool: 

In fact, there was a recent discussion on gentoo-dev on exactly this problem, check out the thread here:

http://marc.theaimsgroup.com/?l=gentoo-dev&m=108941546210506&w=2

Obviously many people feel that there are too many patch-specific kernels in the portage tree. Also there are a few deprecated platform-specific ones like ppc-dev. 

You might want to check out ketchup, a Python script to handle automatic patch managment with kernels.

Say you are running a 2.6.7-mm2 kernel and want to update to the latest mm sources, you would do:

```
$ ketchup 2.6-mm

 2.6.7-mm2 -> 2.6.8-rc1-mm1

 Applying 2.6.7-mm2.bz2 -R

 Applying patch-2.6.8-rc1.bz2

 Downloading 2.6.8-rc1-mm1.bz2

 Downloading 2.6.8-rc1-mm1.bz2.sign

```

Ketchup figures out the latest version of the patchset you want (currently 2.6.8-rc1-mm1), reverses any applied patches (the -mm2), downloads new patches, checks their signatures and applies them. It currently works only with -mm, -tiny and -mjb patchsets though.

Kerneltrap discussion

Download

This is already pretty cool, but a patchset configuration file where I could manually add my own favourite patches to be automatically included when a new version of a kernel is emerged would be really nice (I run -ck kernels with a few other patches that I apply).

This way people could also concentrate on updating their patches & fixing hunks instead of additionally having to care about updating the ebuild.

Cheers,

DiskBreaker

----------

## Serj

 *DiskBreaker wrote:*   

> You might want to check out ketchup, a Python script to handle automatic patch managment with kernels.
> 
> ...
> 
> Ketchup figures out the latest version of the patchset you want (currently 2.6.8-rc1-mm1), reverses any applied patches (the -mm2), downloads new patches, checks their signatures and applies them. It currently works only with -mm, -tiny and -mjb patchsets though.

 

Great! I think it's posible to use this tool as a base for future mechanism of installing linux kernel in Gentoo. It's necessary to offer this to gentoo kernel maintainers. Can anybody do this?

----------

## Gentii

I think it'll complicate things more than it helps. If you're not happy with portage, just install the kernels yourself. But I don't see the matter in portage.

You just have to do : emerge gentoo-dev-sources, development-sources, ck-sources, mm-sources.

And for the loves one, you just have to create a portdir overlay and put the love ebuilds in, then it's emerge love-sources.

----------

## Serj

 *Gentii wrote:*   

> I think it'll complicate things more than it helps.

 

I think differently... The main point of my idea is to simplify the installation of linux kernel. You right, there are many ebuilds in portage now for diffrent kernels, but I think it's simpler to have only one ebuild!  

And if you whant to create your own kernel? You must create your own ebuild (Yes, you can apply patches manualy, but you love Portage, right? And me too  :Wink:  ). I think it's easier to create kernel profile then kernel ebuild!

 *Gentii wrote:*   

> If you're not happy with portage, just install the kernels yourself. 

 

I like Portage but I am not a guru.  :Smile: 

----------

## spb

One thing that stands out: what's going to happen with security updates? At the moment, a version bumped ebuild comes out, and Portage updates it automatically. With this scheme, you lose that possibility, since all 2.6.7 kernels have the same version number. 

As for creating your own kernel ebuild, it's quite simple. Apply all the patches you want onto a kernel source tree, fixing up any problems, make a big diff file, stick it into /usr/portage/distfiles, then take the love-sources (for example) ebuild, and change the revision-specific variables to point to your patch.  With this scheme, you're still going to have to create a big patch manually, since almost any non-trivial combination of patches is going to require manual fixups.

----------

## Serj

 *thebell wrote:*   

> With this scheme, you lose that possibility, since all 2.6.7 kernels have the same version number. 

 

Why?!! You can add fixed patches for 2.6.7-r1, 2.6.7-r2,... etc. Check my previous post with examples of /etc/kernel.

 *thebell wrote:*   

> As for creating your own kernel ebuild, it's quite simple. Apply all the patches you want onto a kernel source tree, fixing up any problems, make a big diff file, stick it into /usr/portage/distfiles, then take the love-sources (for example) ebuild, and change the revision-specific variables to point to your patch.  With this scheme, you're still going to have to create a big patch manually, since almost any non-trivial combination of patches is going to require manual fixups.

 

Are you sure your method is quite better than mine? Yes, we can do all things by hands. But I like Gentoo more than LFS.  :Smile: 

----------

## spb

 *Serj wrote:*   

> Are you sure your method is quite better than mine? Yes, we can do all things by hands. But I like Gentoo more than LFS. 

 My point is that if you want to create your own custom kernel, you have to go through the same process of manually patching and fixing rejects with either method, so it doesn't make custom kernels any simpler.

Basically, I just think this is going to be more complicated to implement, and not really any simpler to use. How are you going to update the list of available kernels? Part of emerge sync? In that case, quite apart from adding more complexity to emerge's sync code, you'll need a seperate kernel overlay directory so that rsync doesn't delete your custom ones. 

As for emerging 'kernel-2.6.7-r10', what if I'm using mm-sources, which are currently at 2.6.7-r7, when a gentoo-dev-sources-2.6.7-r10 comes out? Are you going to release a kernel-2.6.7-r10 ebuild which will show up in my world updates, even though the source tree I'm using hasn't reached that version number? That's going to cause no end of confusion.

Basically, if someone can come up with a proof-of-concept implementation that updates available kernels with an 'emerge --sync', handles differing version numbers on source trees elegantly, and simplifies making custom patchsets, as you seem to be promising, then I'll agree that it's a better method than what we have.

----------

