[Dev] linux-kernel-headers package

Karol Lewandowski k.lewandowsk at samsung.com
Tue Feb 4 18:44:55 GMT 2014

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.


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:artem.bityutskiy at linux.intel.com]
>>> 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
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev

More information about the Dev mailing list