[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debian] Kernel Include ?

On Sun, Jan 07, 2001 at 01:30:15PM +0100, Robert Rakowicz wrote:
> ist das denn so richtig daß bei Debian ( kann nur von meiner LinuxLand
> Potato sprechen ) sich die Header des Kernels im /usr/include/linux
> befinden ? Ich bin natürlich voll auf die Nase gefallen, da ich gehe
> immer davon aus des es ein Link auf /usr/src/linux/include/linux ist.

Siehe http://www.linuxfaq.de/f/cache/57.html, unten gedumped.

Sorry für die Formatierung (w3m ist - natürlich - schuld. :)

 [Suche] [Darstellung] 
(Answer)  (Category) Linux User FAQ : (Category) Programmierung unter Linux : (Category)   
          Tips für Selber-kompilieren von Software :                                       
          Was ist der Unterschied zwischen `/usr/src/linux/include' und `/usr/include/     
          Achtung Fortgeschrittenen-Info                                                   
          Warum gibt es `/usr/src/linux/include' (in den Kernelquellen) und `/usr/include/ 
          linux' (in dem System-Includeverzeichnis)? Welches sollte ich benutzen? Warum    
          kompilieren einige Programme nicht, oder meckern über 'falsche Kernel-Header'?   
          Hier ist eine etwas ältere, aber noch aktuelle Erklärung, wozu es diese beiden   
          Verzeichnisse gibt, warum sie getrennt wurden, woher sie kommen, und warum seit  
          einiger Zeit aus `/usr/include/linux/errno.h' die letzte Zeile aus der folgenden 
           #define EPERM    1              /* Operation not permitted */                   
           #define ENOENT   2              /* No such file or directory */                 
           #define EMACS  666              /* Editor too large */                          
          herausgenommen wurde. ;-)                                                        
          Here is the rationale of the `/usr/include/linux' vs. `/usr/src/linux/include/   
          linux' issue. (sorry, I don't have any reference to this, so I have to include   
          all the text here) Basically the kernel headers match the kernel. The `/usr/     
          include' headers match the program development tools. This allows to separate    
          kernel and libc development.                                                     
          Here is the story:                                                               
          The headers were included in `libc5-dev' after a rash of very buggy alpha kernel 
          releases (1.3.7* or something like that) that proceeded to break compilations,   
          etc. Kernel versions are changed far more rapidly than libc is, and there are    
          higer chances that people install a custom kernel than they install custom LIBC. 
          LIBC6 includes it's own version of `/usr/include/linux' and friends form the     
          beginning (that is, this is no longer a `Debian' only feature, the upstream      
          version has moved to this scheme as well).                                       
          >> "Linus" == Linus Torvalds said on Wed, 22 Jan 1997:                           
          The kernel headers used to make sense exporting to user space, but the user space
          thing has grown so much that it's really not practical any more. The problem with
          Debian is just that they are different, not that they are doing anything wrong.  
          That leads to differences between the distributions, and that in turn obviously  
          can result in subtle problems. As of GLIBC, the kernel headers will really be    
          _kernel_ headers, and user level includes are user level includes. Matthias      
          Ulrich did that partly because I've asked him to, but mainly just because it is  
          no longer possible to try to synchronize the libc and the kernel the way it used 
          to be. The symlinks have been a bad idea for at least a year now, and the problem
          is just how to get rid of them gracefully. Personally, I'm counting on GLIBC,    
          which we are already using on alpha. Just to give you some idea of exactly why   
          the includes really can't be handled by simple symlinks: the main problem is     
          version skew. Lots of people want to upgrade their library without affecting the 
          kernel, and probably even more people want to be able to upgrade their kernel    
          without affecting their compilation environment. Right now doing that has been   
          extremely fragile. Just to give _one_ example of why the symlinks are bad:       
          NR_OPEN and fd_set. I have had no end of problems making NR_OPEN larger in the   
          kernel, exactly _because_ of the damn sym-links.                                 
          If I just make NR_OPEN larger (the right thing to do), the problem is that people
          with old libraries will now compile against a header file that doesn't match the 
          library any more. And when the library internally uses another NR_OPEN than the  
          new program does, "interesting" things happen. In contrast, with separate header 
          files, this doesn't make any difference. If I change NR_OPEN in the kernel, the  
          compilation environment won't notice until the library and associated header     
          files are changed: thus the user will contine to compile with the old values, but
          because we'll still be binary compatible, the worst thingthat happens is that new
          programs won't take advantage of new features unless the developer has upgraded  
          his library. Compare that to breaking subtly. NR_OPEN is just _one_ example, and 
          actually it's one of the easier ones to handle (because the only thing that      
          really makes much of a difference when it comes to NR_OPEN is the fd_set size -- 
          but it certainly bit some people). Another major problem is name-space pollution:
          the POSIX/ANSI/XOPEN rules are not only complex, but they are actually           
          contradictory too. And the kernel header files really can't reasonably support   
          all of the intricacies very cleanly. One specific example of why we want separate
          header files for libraries and kernel is offered by glibc: Matthias wanted to    
          have a sigset_t that will suffice for the future when the POSIX.1B realtime      
          signals are implemented. But at the same time he obviously wants to be able to   
          support programming on Linux-2.0 and the current 2.1 that do not have that       
          support. The only reasonably clean way to handle these kinds of problems is to   
          have separate header files: user programs see a larger sigset_t, and then the    
          library interaction with the kernel doesn't necessarily use all of the bits, for 
          example. Then later, when the kernel support is actually there, it's just a      
          matter of getting a new shared library, and voila, all the realtime signals work.
          The symlink approach simply wouldn't work for the above: that would have required
          everybody who uses the library to have a recent enough kernel that whatever magic
          all the above entails would be available in the kernel header files. But not only
          don't I want to pollute the kernel header files with user level decisions, it's  
          actually possible that somebody wants to run glibc on a 1.2.x kernel, for        
          example. We definitely do not want him to get a 32-bit sigset_t just because he  
          is happy with an old kernel. Anyway, this email got longer than intended, but I  
          just wanted to make clear that the symlinks will eventually be going away even in
          non-Debian distributions. Debian just happened to do it first -- probably because
          Debian seems to be more interested in technical reasons than any old traditions. 
          And technically, the symlinks really aren't very good. The only reason for the   
          symlinks is to immediately give access to new features in the kernel when those  
          happen. New ioctl numbers etc etc. That was an overriding concern early on: the  
          kernel interfaces expanded so rapidly even in "normal" areas that having the     
          synchronization that symlinks offered was a good thing.                          
          However, the kernel interfaces aren't really supposed to change all that quickly 
          any more, and more importantly: the technical users know how to fix things any   
          way they want, so if they want a new ioctl number to show up they can actually   
          edit the header files themselves, for example. But having separation is good for 
          the non-technical user, because there are less surprises and package             
          Anyway, something like the patch that David suggested will certainly go in,      
          although I suspect I'll wait for it to become "standard" and the glibc first real
          release to take place.                                                           
          Add to that the fact that few programs really need the more volatile elements of 
          the header files (that is, things that really change from kernel version to      
          kernel version), [before you reject this, consider: programs compiled on one     
          kernel version usually work on other kernels].                                   
          So, it makes sense that a set of headers be provided from a known good kernel    
          version, and that is sufficient for compiling most programs, (it also makes the  
          compile time environments for programs on debian machines a well known one,      
          easing the process of dealing with problem reports), the few programs that really
          depend on cutting edge kernel data structures may just use -I/usr/src/linux/     
          include (provided that kernel-headers or kernel-source exists on the system).    
          Most programs, even if they include <linux/something.h>, do not really     
          depend on the version of the kernel, as long as the kernel versions are not too  
          far off, they will work. And the headers provided in `libc5-dev' (and            
          `libc6-dev') are just that.                                                      
          `libc5-dev' is uploaded frequently enough that it never lags too far behind the  
          latest released kernel. libc6 has totally disconnected the included headers from 
          kernel headers.                                                                  
          There are two different capabilities which are the issue, and the kernel-packages
          and `libc{5,6}-dev' address different ones:                                      
           - The kernel packages try tp provide a stable, well behaved kernel and modules, 
             and may be upgraded whenever there are significant advances in those          
             directions (bug fixes, more/better module support, etc). These, however,      
             may not have include files that are non-broken as far as non-kernel programs  
             are concerned, and the quality of the development/compilation environment is  
             not the kernel packages priority (Also, please note that the kernel           
             packages are tied together, so kernel-source, headers, and image are produced 
             in sync)                                                                      
           - Quality of the development/compilation environment is the priority of         
             `libc{5,6}-dev' package, and it tries to ensure that the headers it provides  
             would be stable and not break non-kernel programs. This assertion may fail    
             for alpha kernels, which may otherwise be perfectly stable, hence the need    
             for a different set of known-good kernel include files.                       
          [Diesen Eintrag erweitern]                                                       
Vorhergehende: (Answer) Was wird wohin installiert, kann ich es sauber     
               wieder entfernen?                                           
      Nächste: (Answer) "Hilfe! Mein Programm ist abgestürzt!" oder "Eine  
               kleine Segmentation Fault Einführung"                       
Dieses Dokument ist: http://www.linuxfaq.de//cgi-bin/fom?file=57
 [Suche]     [Darstellung]      
Dies ist eine Faq-O-Matic 2.710.
This FAQ administered by Jens Benecke

A: "Ist [...] noch am Leben?"
B: "Sie wurde zusammen mit ihrem Mann begraben."
A: "Das beantwortet meine Frage nicht!"
http://www.hitchhikers.de/ - Die kostenlose Mitfahrzentrale für ganz Europa

Attachment: pgptMlCKEDGQZ.pgp
Description: PGP signature

Reply to: