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? 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
