[Dev] linux-kernel-headers package
k.lewandowsk at samsung.com
Tue Feb 4 18:44:55 GMT 2014
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 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)
> 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
>>> 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.
>> Actually, I also tried to remove the header package is out from the
>> linux-3.10 tree.
>> 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 
> - we drop pre-processed headers in the form of linux-glibc-devel
> - 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
> (On the bad side - this could be rather time consuming.)
>>  : https://review.tizen.org/gerrit/#/c/14966/
> Dev mailing list
> Dev at lists.tizen.org
More information about the Dev