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. But it does make sense to update them sometimes because kernel constantly gets new features and faster ways to do things, and glibc may do things better when it is compiled with newer headers. Or there may be new features wanted. > As I know, the IVI kernel will be updated according to > latest linus tree. Not really. We could do this if needed. Our motivation to upgrade kernel headers is to get new features. I do not remember what exactly that was last time, but I think something related to OpenAVB. But once we updated the kernel headers because there was a typo in them, fixed in one of the -stable kernels. But this is an extremely rare case. > 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. > 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). 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? -- Best Regards, Artem Bityutskiy _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
