kprobes-enabled kernel

[trickie]

This patch adds a bitbake recipe (and associated patches) for the maemo 4.0 kernel with backported kprobes. systemtap (see #131) requires a kprobes enabled kernel.

This patch also relies on the sourcedsc patch from #120 being applied, which will make a kernel source package that is buildable in the SDK and which you can compile systemtap kernel modules against.

[trickie]

kprobes enabled kernel

[trickie]

I will try and update this with the diablo kernel source now that it is released officially.

[rsalveti]

Replying to trickie:

I will try and update this with the diablo kernel source now that it is released officially.

That's what I was going to ask you. Probably you're not going to face any problem applying the patches on diablos's kernel, but it would be good if you could verify if it's working as expected.

Just post your new patch and I'll take a look.

Thanks,

rsalveti

[rsalveti]

Just a reminder for me to also add this patch before closing this ticket:

http://trickie.xs4all.nl/?p=mamona;a=commitdiff;h=6830c2c355dd05a77caadecedcf2ee16b7eaf87c;hp=e6b40ebf81891d71bacb997877c913d5d617b34a

[trickie]

updated kprobes patch for chinook and diablo kernels

[trickie]

task for building sdk + systemtap

[trickie]

Replying to rsalveti:

Replying to trickie:

I will try and update this with the diablo kernel source now that it is released officially.

That's what I was going to ask you. Probably you're not going to face any problem applying the patches on diablos's kernel, but it would be good if you could verify if it's working as expected. Just post your new patch and I'll take a look.

Attached, with recipes for chinook and diablo kernels for both n800 and n810

Thanks, rsalveti

[trickie]

Replying to rsalveti:

Just a reminder for me to also add this patch before closing this ticket: http://trickie.xs4all.nl/?p=mamona;a=commitdiff;h=6830c2c355dd05a77caadecedcf2ee16b7eaf87c;hp=e6b40ebf81891d71bacb997877c913d5d617b34a

I have attached a newer patch for this also. I rebase my patches on top mamona.git HEAD so that old commit doesn't exist anymore.

[rsalveti]

Both patches applied, the first one I did another patch on top to remove duplicated code and to add default preference for n810. The second patch I applied by hand, to let it look like the others tasks we have at mamona.

Another comment about the first patch:

Note that at linux-nokia800-kprobes_2.6.21-osso71 the bb file has "inherit sourcedsc", should this be the default behavior from this package?

The diablo kprobes' kernel doesn't have this line, and maybe it should be a user decision to build the source or not, what do you think?

Thanks,

rsalveti

[trickie]

Replying to rsalveti:

Hi

Both patches applied, the first one I did another patch on top to remove duplicated code and to add default preference for n810. The second patch I applied by hand, to let it look like the others tasks we have at mamona.

Excellent. Thanks

Another comment about the first patch: Note that at linux-nokia800-kprobes_2.6.21-osso71 the bb file has "inherit sourcedsc", should this be the default behavior from this package?

Yes that slipped in. I build source packages for all my kernels, but i guess that should not be the default.

The diablo kprobes' kernel doesn't have this line, and maybe it should be a user decision to build the source or not, what do you think?

I agree. I can change the patches if you need me to.

Thanks, rsalveti

[rsalveti]

Replying to trickie:

The diablo kprobes' kernel doesn't have this line, and maybe it should be a user decision to build the source or not, what do you think?

I agree. I can change the patches if you need me to.

Just send me a patch fixing that and I'll apply.

[trickie]

remove source package creation for kprobes kernel

[trickie]

Replying to rsalveti:

Replying to trickie:

The diablo kprobes' kernel doesn't have this line, and maybe it should be a user decision to build the source or not, what do you think?

I agree. I can change the patches if you need me to.

Just send me a patch fixing that and I'll apply.

Attached. I cannot get to the OE commit policy (server seems dead), so i hope patches like this are ok.

Cheers

[rsalveti]

http://dev.openbossa.org/mamona/gitweb?p=mamona.git;a=commit;h=c13d78da37fb8d21559923e6c78453fd6256b39d

Added.

The patch is fine, I would just recommend you to add the name of the recipe being modified at the beginning of the commit message.

[rsalveti]

There's just one issue that I saw when creating 0.2-beta that I'd like to verify before closing this ticket, that's the name of the packaged created by the kprobes enabled kernel's recipe.

I saw that the kprobes' enabled kernel was named like the normal kernel, so there could be a problem if you're trying to build both kernels (e.g. you want the default but you also want to have the possibility to change to the kprobes' enabled one).

Don't know if this is a valid situation, need to think more about it, but it could be a problem. For me something like kernel-kprobes sounds better than just "kernel", what do you think?

[trickie]

Replying to rsalveti:

Hi,

There's just one issue that I saw when creating 0.2-beta that I'd like to verify before closing this ticket, that's the name of the packaged created by the kprobes enabled kernel's recipe. I saw that the kprobes' enabled kernel was named like the normal kernel, so there could be a problem if you're trying to build both kernels (e.g. you want the default but you also want to have the possibility to change to the kprobes' enabled one). Don't know if this is a valid situation, need to think more about it, but it could be a problem. For me something like kernel-kprobes sounds better than just "kernel", what do you think?

Yeah ok, sounds like there could be confusiion/conflicts there. I had never thought about it actually.

Is this just a case of changing PACKAGES after you 'inherit kernel' ?

Ill try that today.

Cheers

[trickie]

Replying to trickie:

Hi again,

Replying to rsalveti: Hi,

There's just one issue that I saw when creating 0.2-beta that I'd like to verify before closing this ticket, that's the name of the packaged created by the kprobes enabled kernel's recipe. I saw that the kprobes' enabled kernel was named like the normal kernel, so there could be a problem if you're trying to build both kernels (e.g. you want the default but you also want to have the possibility to change to the kprobes' enabled one). Don't know if this is a valid situation, need to think more about it, but it could be a problem. For me something like kernel-kprobes sounds better than just "kernel", what do you think?

Yeah ok, sounds like there could be confusiion/conflicts there. I had never thought about it actually. Is this just a case of changing PACKAGES after you 'inherit kernel' ? Ill try that today.

Well I tried that, but it is going to be messy. We will basically have to not use the packages/linux/linux-nokia800.inc or the kernel.bbclass if we want to change the end package names.

I can try to make a patch for that, but I think it is not worth it. What do you think?

Cheers

[rsalveti]

Replying to trickie:

Well I tried that, but it is going to be messy. We will basically have to not use the packages/linux/linux-nokia800.inc or the kernel.bbclass if we want to change the end package names. I can try to make a patch for that, but I think it is not worth it. What do you think?

Hm, don't think it's worth, the package name is too tight at kernel.bbclass.

But can't think of a good solution, just some alternatives:

1. Don't build any kernel and let the responsibility to the user.
2. Build just the default kernel of the machine and let the kprobes enabled kernel available somewhere else (just the debs).
3. Incorporate the kprobes patches at the official kernel, letting just one alternative to the user (like most recipes).

What do you think?

[trickie]

Replying to rsalveti:

Hey!

Replying to trickie:

Well I tried that, but it is going to be messy. We will basically have to not use the packages/linux/linux-nokia800.inc or the kernel.bbclass if we want to change the end package names. I can try to make a patch for that, but I think it is not worth it. What do you think?

Hm, don't think it's worth, the package name is too tight at kernel.bbclass.

Agreed.

But can't think of a good solution, just some alternatives: 1. Don't build any kernel and let the responsibility to the user. 1. Build just the default kernel of the machine and let the kprobes enabled kernel available somewhere else (just the debs).

Well for now it only builds linux-nokia800 unless you ask specifically for linux-n800-kprobes. People wanting to build a kprobes enabled kernel will probably be able to swap out the default kernel if they need to. They will need to have the mamona OE tree setup though...

1. Incorporate the kprobes patches at the official kernel, letting just one alternative to the user (like most recipes).

We could do that. There is a slight performance impact of having kprobes enabled, even if you are not using them, and also this is a backport that doesn't have the polish of the offical kprobes for ARM in later kernels.

Those are the reasons I didn't propose to add these patches to the default kernel, and instead make a new kernel recipe.

What do you think?

Id say unless there is quite some demand for a kprobes enabled kernel we leave it as is (the second option), and let people who want it build it themselves.

If there is demand later then we can merge the patches to the default kernel or spend the effort to make the recipe not use kernel.bbclass

[rsalveti]

Replying to trickie:

Well for now it only builds linux-nokia800 unless you ask specifically for linux-n800-kprobes. People wanting to build a kprobes enabled kernel will probably be able to swap out the default kernel if they need to. They will need to have the mamona OE tree setup though...

Yeah, agreed.

1. Incorporate the kprobes patches at the official kernel, letting just one alternative to the user (like most recipes).

We could do that. There is a slight performance impact of having kprobes enabled, even if you are not using them, and also this is a backport that doesn't have the polish of the offical kprobes for ARM in later kernels. Those are the reasons I didn't propose to add these patches to the default kernel, and instead make a new kernel recipe.

What do you think?

Id say unless there is quite some demand for a kprobes enabled kernel we leave it as is (the second option), and let people who want it build it themselves. If there is demand later then we can merge the patches to the default kernel or spend the effort to make the recipe not use kernel.bbclass

Agreed, sounds a good plan :-)

Thanks, think we can close this ticket now.