Hi Stephane, You maintain Tizen:Generic kernel which is supposed to provide common base for other verticals.
Do you think it would make sense (and be feasible) to generate kernel-headers package out of it? (Each vertical would then use it). Please see below for backstory. Cheers, Karol On 01/17/2014 07:01 PM, Karol Lewandowski wrote: > On 01/17/2014 05:12 AM, Chanho Park wrote: > > Hi, > >> Hi Artem, >>> From: Artem Bityutskiy [mailto:[email protected]] > >>> Hi Chanho, >>> >>> I was myself thinking about this recently and also not 100% sure. Let me >>> comment on some of your question, and add few more questions too :-) > >>> On Thu, 2014-01-16 at 11:10 +0900, Chanho Park wrote: > >>>> The package is generated from linux-glibc-devel repository which have >>>> static kernel header files. However, IVI kernel and mobile(RD-PQ) are >>>> different kernel version. >>> >>> This is very rarely a problem. Kernel headers represent Linux kernel ABI >>> which is extremely stable. E.g., glibc compiled against v3.0 will work >>> perfectly fine with v3.12. >> >> Agree. I also think this case is very rarely. > > What I dislike most about linux-glibc-devel repo is that it does contain > exported, pre-processed headers from completely different (unknown) > source. > > In other words - we take some kernel sources, manually run "make > headers_install", put the end result into completely new repo and > call it *source* again. This is far from being elegant, but I do > know it solves some hard problems. >>>> I don't know much of the package dependencies. I'm not sure whether the >>>> Header package should be updated according to kernel version. >>> >>> It may be. AFAICS, nowadays some distributions do this. In the past the >>> common approach was that kernel headers do not change often. >>> >>> I do not know why one would change kernel headers every time the kernel >>> changes. Sounds just like useless work. > > Agreed, this is waste of resources and this is why I think current > (linux-glibc-devel) approach has it good points. > > >>>> For example, the IVI kernel is updated kernel 3.14, does the header >>>> package need to be updated to the 3.14? >>> >>> No, why bother? Only if someone requests for this because there was a >>> new useful syscall they want to use. > > ... > >>>> If so, IMO the header package should be generated from its own kernel >>>> repository. >>> >>> May be, but I'd really like to understand why, what for? I see a benefit >>> of giving apps all the newest features. On the other hand, glibc won't >>> support many of them anyway, can it confuse apps somehow (e.g., a >>> syscall is there in the kernel headers, but glibc does not have a nice >>> usable wrapper around it). > > There is more (albeit a little) to kernel <-> userspace api that just > what glibc offers. Take all the constants and magic ioctl numbers that > are used - these can change freely without glibc ever knowing. > > Maybe it's my personal bias, because I watched how video4linux2 *.h > files have changed rapidly, and wanted to prevent frameworks/apps > from ever needing to include their own copy of these... > > >>> I personally tend to think that kernel headers should be updated rarely >>> and in a controllable manner. This just feels more secure, more of a >>> "defensive" development. >>> >>> Hmm? >> >> Actually, I also tried to remove the header package is out from the >> linux-3.10 tree.[1] >> >> To Karol and Jacek, >> What about your thoughts of this issue. Can I remove the package is out >> from the linux-3.10? Here is what I'm proposing: > What about finding some middle ground here: > > - we abandon kernel-generated headers from mobile repo [1] > > - we drop pre-processed headers in the form of linux-glibc-devel > *repository* > > - we adjust tizen-generic kernel to export linux-glibc-devel > *package* straight from actual kernel sources > > Then, we would make all potentially userspace-visible changes to the > kernel go through kernel-generic before it lands profile-specific > one. > > (On the bad side - this could be rather time consuming.) > >> [1] : https://review.tizen.org/gerrit/#/c/14966/ > > Cheers, > Karol > > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev > _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
