Hlavní navigace

Linux se v roce 2017 zvětšil o dva a půl miliónů řádků kódu

2. 1. 2018

Sdílet

Celkem proběhlo 71 552 commitů, tedy přibližně 196 commitů každý den v roce. Celkově do jádra přibyly téměř 4 milióny řádků zdrojového kódu, naopak necelého 1 a půl miliónu řádků zmizelo, což dává celkově zhruba o 2,5 miliónů řádků kódu větší projekt.

Jelikož loni, resp. předloni přišlo do projektu ~77, resp. ~76 tisíc commitů, byl loňský rok vlastně z hlediska revize commitů méně náročným, předchozí z tohoto hlediska slabší rok byl až 2013. Na druhou stranu ale počet commitů × počet řádků kódu jsou dvě rozdílné věci a vloni do Linuxu přibylo opravdu hodně zdrojáku, ač hodně velké množství připadá na hlavičkové soubory a podobné záležitosti, což plyne například z velké práce odvedené komunitou a vývojáři AMD na ovladači AMDGPU.

Vedle Linuse Torvaldse byli nejpracovitějšími autory patchů David S. Miller, Arnd Bergmann, Chris Wilson, Arvind Yadav a Christoph Hellwig. Většinu příspěvků do jádra z hlediska firem přinesl opět Intel, druhým pak byl Red Hat. Linux aktuálně nese přes 62 tisíc souborů a celkový počet řádků zdrojového kódu téměř 25 a půl miliónů. Kompletní přehled shrnuje Phoronix na samostatné stránce.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 2. 1. 2018 20:15

    kutr (neregistrovaný)

    "... ač hodně velké množství připadá na hlavičkové soubory a podobné záležitosti, což plyne například z velké práce odvedené komunitou a vývojáři AMD na ovladači AMDGPU."
    Ne, to spíš plyne z historických deficitů jazyků C/C++, že hlavičkové soubory jsou vůbec potřeba.

  • 2. 1. 2018 21:55

    martin1397

    V tomto ohľade som pomerne nevzdelaný ale ako je to pri kompilácii? Kompilujú sa všetky tie riadky alebo sa nejaké veľké kusy vynechávajú podla platformy? A ak áno tak koľko % približne z tých zdrojákov využíva nejaká priemerná distribúcia ako Debian?

  • 3. 1. 2018 1:59

    peci1
    Stříbrný podporovatel

    To prave zalezi na nastaveni kazde distribuce, co "pribali" do stock jadra, co dovoli jako modul, a co nezahrne vubec. Ja treba mel dost problem se starsi wifi kartou od Broadcomu, kdyz se Ubuntu rozhodlo, ze v jadre bude nova verze driveru, ktera se vzajemne vylucuje s tou, kterou potrebovala moje karta. Obecne ted dost mainstream distribuci upousti od prikladani driveru pro velmi stary HW.

    Pri sestavovani jadra se da nastavit, co vsechno clovek chce, pomoci napr. menuconfig: https://en.wikipedia.org/wiki/Menuconfig#/media/File:Linux_x86_3.10.0-rc2_Kernel_Configuration.png .

    Hloubeji do technikalii nevidim, ale predstavuju si to tak, ze kazda volba v menuconfigu bud splni a nebo nesplni nejakou template promennou, a v kodu pak jsou #ifdefy. Plus jsou samozrejme ruzne kody pro ruzne platformy, a vzdycky se sestavuje jen to, co ma smysl (opet bud pomoci #ifdef, nebo je to dano adresarovou strukturou jadra).

    Dobre cteni je tady: https://superuser.com/a/370588/255660 .

  • 10. 1. 2018 8:58

    Lael Ophir

    Ze mého pohledu ze značné dálky vyplývá tohle (rád se nechám opravit někým kdo o věci ví víc):

    To co si vybíráte v menuconfig se bere z adresáře linux/arch/[ar­chitektura]]/Kcon­fig, například linux/arch/x86/Kcon­fig. Tam najdete jednotlivé volby a jejich popis (často žádný neexistuje), a jsou tam i linky na další Kconfig soubory nezávislé na architektuře.

    Vybrané volby se zapíšou do souboru .config, který nastavuje proměnné. Například volba MICROCODE_AMD má v UI popis "AMD microcode loading support", má dokonce help text "If you select this option, microcode patch loading support for AMD processors will be enabled.", a nastaví v .config MICROCODE_AMD=y. Pokud volba není zapnutá, najdete v .config komentář typu # MICROCODE_AMD is not set.

    Při kompilaci se nějakým skriptem vytváří ze souboru .config header include/genera­ted/autoconf.h, ve kterém najdete vlastní #define MICROCODE_AMD. Ve zdrojáku je pak použitý #ifdef. Například v linux/arch/x86/in­clude/asm/micro­code_amd.h uvidíte, jak se metody #ifdefem mění na prázdný inline blok:

    #ifdef CONFIG_MICROCO­DE_AMD
    extern void __init load_ucode_am­d_bsp(unsigned int family);
    extern void load_ucode_am­d_ap(unsigned int family);
    extern int __init save_microcode_in_i­nitrd_amd(unsig­ned int family);
    void reload_ucode_am­d(void);
    #else
    static inline void __init load_ucode_am­d_bsp(unsigned int family) {}
    static inline void load_ucode_am­d_ap(unsigned int family) {}
    static inline int __init
    save_microcode_in_i­nitrd_amd(unsig­ned int family) { return -EINVAL; }
    void reload_ucode_am­d(void) {}
    #endif

    Pokud jde o moduly, tak ty jsou v Kconfig (nejčastěji pod větví linux/drivers) jako tristate, a v .config skončí hodnota y (statická kompilace) nebo m (dynamický modul). V makefiles jsou pak použité konstrukce, které používají ty proměnné, typicky takto:
    obj-$(CONFIG_SCSI) += scsi_mod.o
    A to nakonec skončí sesbíráním object files do kernel image a modulů.

  • 10. 1. 2018 19:56

    martin1397

    Ďakujem veľmi pekne za tak rozsiahlu odpoveď :)

Byl pro vás článek přínosný?

Autor zprávičky

Příznivec open-source rád píšící i o ne-IT tématech. Odpůrce softwarových patentů a omezování občanských svobod ve prospěch korporací.