Linus關於核心標頭檔案與核心原始碼關係的論述(轉)
Linus關於核心標頭檔案與核心原始碼關係的論述(轉)[@more@]
CODE:
From: Linus Torvalds (torvalds@transmeta.com)
Date: Thu Jul 27 2000 - 02:39:51 EST In article Boszormenyi Zoltan > >/usr/include/asm is a symlink to /usr/src/linux/include/asm, as in the >original distribution but /usr/src/linux is a 2.4.0-testX tree. >With a 2.2.X source tree, it does not produce any warning. I've asked glibc maintainers to stop the symlink insanity for the last few years now, but it doesn't seem to happen. Basically, that symlink should not be a symlink. It's a symlink for historical reasons, none of them very good any more (and haven't been for a long time), and it's a disaster unless you want to be a C library developer. Which not very many people want to be. The fact is, that the header files should match the library you link against, not the kernel you run on. Think about it a bit.. Imagine that the kernel introduces a new "struct X", and maintains binary backwards compatibility by having an old system call in the old place that gets passed a pointer to "struct old_X". It's all compatible, because binaries compiled for the old kernel will still continue to run - they'll use the same old interfaces they are still used to, and they obviously do not know about the new ones. Now, if you start mixing a new kernel header file with an old binary "glibc", you get into trouble. The new kernel header file will use the _new_ "struct X", because it will assume that anybody compiling against it is after the new-and-improved interfaces that the new kernel provides. But then you link that program (with the new "struct X") to the binary library object archives that were compiled with the old header files, that use the old "struct old_X" (which _used_ to be X), and that use the old system call entry-points that have the compatibility stuff to take "struct old_X". Boom! Do you see the disconnect? In short, the _only_ people who should update their /usr/include/linux tree are the people who actually make library releases and compile their own glibc, because if they want to take advantaged of new kernel features they need those new definitions. That way there is never any conflict between the library and the headers, and you never get warnings like the above.. >Mr. Ulrich Drepper (one of the glibc/gcc guys) gave me a standard >"don't use kernel headers directly" answer. But neither gcc.c, >neither the above small program use kernel headers. I suppose he >referred to /usr/include/linux/* as (I think) he did not understand me. No. He really meant that you should not use the kernel headers: you should use the headers that glibc came with. It is probably a redhat bug that those headers were a symbolic link. I would suggest that people who compile new kernels should: - NOT do so in /usr/src. Leave whatever kernel (probably only the header files) that the distribution came with there, but don't touch it. - compile the kernel in their own home directory, as their very own selves. No need to be root to compile the kernel. You need to be root to _install_ the kernel, but that's different. - not have a single symbolic link in sight (except the one that the kernel build itself sets up, namely the "linux/include/asm" symlink that is only used for the internal kernel compile itself) And yes, this is what I do. My /usr/src/linux still has the old 2.2.13 header files, even though I haven't run a 2.2.13 kernel in a _loong_ time. But those headers were what glibc was compiled against, so those headers are what matches the library object files. And this is actually what has been the suggested environment for at least the last five years. I don't know why the symlink business keeps on living on, like a bad zombie. Pretty much every distribution still has that broken symlink, and people still remember that the linux sources should go into "/usr/src/linux" even though that hasn't been true in a _loong_ time. Is there some documentation file that I've not updated and that people are slavishly following outdated information in? I don't read the documentation myself, so I'd never notice ;) Linus 來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10617542/viewspace-960411/,如需轉載,請註明出處,否則將追究法律責任。
上一篇:
硬碟主引導扇區的結構及功能全面釋疑(轉)
請登入後發表評論
登入
全部評論
|
相關文章
- 關於C++的標頭檔案C++
- gcc 標頭檔案依賴關係 分析工具GC
- 關於傳送Http標頭檔案HTTP
- liunx核心移植(三)——核心、驅動、應用程式、根檔案系統的關係
- Makefile 自動生成標頭檔案的依賴關係
- C語言關於標頭檔案的使用C語言
- 8.14 Linux核心中的標頭檔案Linux
- 論Asp與XML的關係(轉)XML
- 關於hive核心Hive
- 關於vim看linux 核心原始碼時的程式碼補全Linux原始碼
- 關於拉幕程式的討論和原始碼 (轉)原始碼
- 關於控制檔案與資料檔案頭資訊的說明(zt)
- 標頭檔案與庫檔案與菜鳥 (轉)
- 論《金瓶梅》與專案管理中人際關係協調(轉)專案管理
- Linux核心原始碼的閱讀及相關工具介紹(轉)Linux原始碼
- android版本與linux核心版本對應關係AndroidLinux
- uboot環境變數與核心MTD分割槽關係boot變數
- [20170406]關於檔案頭轉儲.txt
- Makefile基礎 4. 自動處理標頭檔案的依賴關係
- Jacek Sliwinski:論述遊戲設計複雜性與成功的關係遊戲設計
- 關於Spring Cloud的核心特性SpringCloud
- 關於專案管理中的公共關係資源管理(轉)專案管理
- Linux核心的framebuffer相關的核心程式碼註釋Linux
- ]Iterator原始碼探究及其與Collection類的關係原始碼
- 關於核心執行緒(kernel_thread)(轉)執行緒thread
- 鴻蒙輕核心原始碼分析:檔案系統LittleFS鴻蒙原始碼
- 關於專案經理的討論 (轉)
- 關於 Linux 核心的10個面試問題與答案Linux面試
- 關於檔案寫入的原子性討論
- IT產品管理與專案管理的關係(轉)專案管理
- 海量文字中挖掘人物關聯關係核心技術介紹
- oracle 關於--密碼檔案Oracle密碼
- 關於oracle 密碼檔案Oracle密碼
- C++標準庫簡介、與STL的關係【轉】C++
- 【核心檔案系統】原始碼閱讀stat.h原始碼
- 關於Web安全趨勢與核心防禦機制Web
- asp.net 中 .ASPX 與.CS檔案的關係ASP.NET
- 關於資料檔案頭的檢查點SCN