Hi, On 09/12/2014 17:23, Maciej Wereski wrote: > Dnia czwartek, 4 grudnia 2014 13:49:22 Dominig ar Foll pisze: >> Hello, >> >> could you please submit your patch to LTS/LTSI 3.14 as well and report >> success or rejection. > > As I've written I'll try to submit memfd also for LTSI. I've got 1 question > though. I've seen that there are many patches (mostly SMACK) on top of both > kernel-common and linux-stable. Were these submitted to LTSI?
Not yet. But I'll take time to do so after the first release of the LTSI kernel. > Nevertheless I'd like to ask for merging these patches anyway. Even if LTSI > won't accept memfd, we will have to backport them. If LTSI accepts memfd, > memfd commits on Tizen kernels can be easily dropped. > > Merging these now means also that backport will be better tested. We're > working on images with kdbus and less differences between kdbus and stock > images means less problems in the future with integrating kdbus. > > Currently we've tested kdbus with kernel-common+memfd on x86_64 and qemu-arm > and there were no problems with memfd. > > We'll do one change though, drop memfd on kernel-common and submit is on > linux-stable (as Patrick suggested, thanks). After that we kindly ask to > merge > memfd regardless of memfd in LTSI status. > > By the way, how should linux-base be tested? According to [1] linux-stable > isn't build, only kernels that base on it. Is testing kernel-common > sufficient? > If it is, then tomorrow I'm going to move memfd patches to linux-stable for > review. 2 remarks about the kernel inheritance model: * we made this model so that profiles maintainers are free to do what they want for their profile. In other words, they can inherit from linux-stable but this is not mandatory. They can also add patches on top, but they will be responsible for maintaining them. * linux-stable is not built, simply because nobody will ever use it. Again, each profile is responsible for its kernel. > [1] <https://wiki.tizen.org/wiki/File:Tizen_Kernel_Inheritance_Model.png> I have a proposal that could probably unlock the situation and give some time to make things correctly. * forget/drop your patches on kernel-common (or linux-stable) * we create a specific git tree for your kdbus integration: platform/kernel/kernel-kdbus (or whatever name you want), and maintainer rights are granted to the kdbus team * you can use the inheritance model for kernel-kdbus, as if it was a profile kernel: inherit from linux-stable, borrow the config to kernel-common, add your own patches (or inherit from kernel-common if easier) * in your devel:kdbus:* OBS projects, disable kernel-common, add kernel-kdbus * also enable _with_kdbus option in your OBS project config (see https://review.tizen.org/gerrit/#/c/31825/) * meanwhile, you can still submit the patches to LTSI (as I'll do for smack patches). At some point, they may get back in linux-stable.git and on next rebase, the patches will be automatically dropped from kernel-kdbus. I think that this specific kernel would be usefull not only for memfd patches but also for upcoming kdbus stuff. When kdbus feature will be mature, it will be time to push it into kernel-common for further intergration then in linux-stable to let all profiles benefit from the feature. => adding the project config flag _with_kdbus makes sense for this transition to be as smooth as possible. Makes sense ? -- Stéphane Desneux Intel OTC - Vannes/FR gpg:1CA35726/DFA9B0232EF80493AF2891FA24E3A2841CA35726 _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
