Linus alapértelmezetté tette a '-Werror' flaget az összes kernelfordításnál

Címkék

Linus a tisztább kernelfordítások érdekében beolvasztotta az 5.15-ös kernelbe az "Enable '-Werror' by default for all kernel builds" változtatást:

Enable '-Werror' by default for all kernel builds ... but make it a config option so that broken environments can disable it when required.

We really should always have a clean build, and will disable specific over-eager warnings as required, if we can't fix them. But while I fairly religiously enforce that in my own tree, it doesn't get enforced by various build robots that don't necessarily report warnings.

So this just makes '-Werror' a default compiler flag, but allows people to disable it for their configuration if they have some particular issues.

Occasionally, new compiler versions end up enabling new warnings, and it can take a while before we have them fixed (or the warnings disabled if that is what it takes), so the config option allows for that situation.

Hopefully this will mean that I get fewer pull requests that have new warnings that were not noticed by various automation we have in place.

Knock wood.
Commit itt.

Hozzászólások

Ezt nem értem. Az összes modulra is vonatkozik? Én most 5.4-ben dolgozom, és abban az általam használt modulok rengeteg warning-ot dobnak. Azokat mind ki kellene pucolni, különben nem fognak lefordulni. 5.15-ben már ennyivel tisztább lenne a kód?

Szerintem 10+ éve nem fordítottam se Linux, se BSD kernelt, de akkoriban mindig rácsodálkoztam, hogy a Linux kernel fordítása mennyit "szemetel" egy BSD kernel fordításához képest. Manapság nem tudom mi a helyzet.

trey @ gépház

Manapság nekem nem sok warning-ot dob, de egy részük feltételezés a fordító részéről, ami vagy igaz, vagy nem...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Nagyon jo lesz, amikor valaki egyel ujabb/regebbi gcc verzioval probalja meg leforditani, mint amivel a maintainerek teszteltek, es akkor szerencsetlen user keresgelheti az opciot hogy hol kell azt a k*va -Wall-t letiltania.

Igen, mar nem egyszer belefutottam hogy random program by default -Werror-al van forditva, aztan nem fordul mert egy ujabb gcc-ben van valami extra warning ami korabbiban nem volt, vagy valami random dependency-ben valami random fuggveny deprecated lett vagy ilyenek.

I hate myself, because I'm not open-source.

Mindez nagyon szep es jo, ha van egy idogeped, kulonben kicsit nehez megoldani hogy a mar kireleaselt kod warning mentesen forduljon egy olyan forditoval, ami a release pillanataban meg nem is letezett. A warning-ot meg nem lehet diagnostic-kent kezelni, mert a -Werror azt mondja hogy minden warning error. Amit lehetne hogy -Werror=akarmi-kkal csak bizonyos warningokat felvenni errornak, es akkor ha egy uj compilerben van egy vadi uj warning, akkor az nem lesz error. De az ellen ez se ved, ha pl. az a logika ami megtalalja az unused variableket abban javitanak valamit, es egy uj verzioban mar olyan eseteket is megtalal amit egy korabbi nem,

TL;DR -Werror-nak van ertelme, a fejleszo gepen. Viszont ugy kiadni a kodot hogy defaultban ott legyen ez a flag, az a felhasznalok szandekos szopatasa. (Aztan a csucs amikor ehhez Makefile-t kell patchelni, mert a fejleszto amikor 3 evvel ezelott kiadta a debian-jan levo akkor mar 5 eves gcc-vel meg lehet warning mentesen fordult...)

I hate myself, because I'm not open-source.

Nalunk a tesztet meg a release elott szoktak lefuttatni, nem kell ehhez idogep. Szoval meg mielott kijon az uj csodagcc, hozzacsapjak a testsethez a kernelt is (ha nincs mar ott eleve). Ha elhasal az uj fordito, akkor lehet menni panaszra a kerneldevekhez, hogy most torjon a kernel vagy ne torjon.

Amugy vihar a biliben a kerdes, mert a futo linuxok jelentos resze *nem* a legujabb gcc-vel forditott, *nem* legujabb verzioju kernelt hasznal. Mire a disztrofejlesztok elkezdenek hozzanyulni csomagolni a kernelt es a forditot, ezek a problemak regen megoldodnak. Akinek meg szerencsetlensegbol kifolyolag bleeding edge cuccot kell hasznalnia, ezeket a problemakat rutinosan fogja workaroundolni. 

Ertem, tehat nem johet ki uj gcc ha felvesznek valami uj warningot ami barmelyik a vilagon valaha kireleaselt kodra warningolni fog. Valoszinu. Amugy meg a gcc fejlesztok pont leszarjak mi van a linux tajan, lasd pl -fstrict-aliasing.

*nem* a legujabb gcc-vel forditott, *nem* legujabb verzioju kernelt hasznal.

Na igen, pont itt lesz a baj, amikor valamelyik random distroban ugy jon ossze a csillagallas hogy a gcc pont fel evvel ujabb mint a kernel.

I hate myself, because I'm not open-source.

Egyfelol, ha annyi rugalmassag van bennuk, mint benned, akkor deadlock-ba lehet kerulni, dehat ez nem az emberiseg normalisabb felenek a problemaja. Amugy meg sehol nem irtam, hogy a valaha volt osszes kodot be kellene emelni a tesztek koze. De mondjuk a linux kernelt be lehetne, merthat reprezentativ peldaja a "kernel kodnak". Az meg, hogy a gcc fejlesztok leszarjak a linux projektet, szinten nem rolam allit ki szegenysegi bizonyitvanyt. Tudom, hogy opensource berkekben csucsmeno mindenbe beleszarni es releaselni majd flamelni, ha nem mukodik, de ebbol normat gyartani eleg necces.

A random disztro majd megoldja a nyugjeit, ha ilyen ezoterikus dolgokba kezd, a legegyszerubb feladata lesz a build scriptbol kiszedni a -werror-t.

Bottom line: erdemes-e egy gcc meretu projektnek figyelnie egy linux kernel meretu/jelentosegu projektre es vica-versa? Igen, szerintem igen, mert mindketto *sok* felhasznalo szamara relevans.

Erdemes-e a gcc fejlesztoknek a linux kernellel foglalkozni? Valoszinuleg. Libreoffice-szal? Szinten. Random hacker444 2 star-al rendelkezo github projectje? Nem. Jo, akkor hol a hatar? Attol hogy linux kernelre felveszunk egy extra kivetelt, az lehet hogy meg fogja oldani a linux kernel bajat, de a maradek open source szoftver 99.9%-anal meg ugyan ugy problema marad. Ilyen szempontbol ertheto, hogy gcc-sek nem akarnak kulon kiveteleket tenni egy (szamukra) random projekt miatt. Meg ugye itt az is problema hogy melyik verzioju kernelt kene a gcc fejlesztoknek tesztelnuk? Git master? Utolso stable release? Osszes LTS? Osszes elmult 1 evben kiadott release? Milyen architekturan? A kernel 28000 config opciojat mire allitsak? Az osszes 3^28000 opciot nyilvan nem lehet kiprobalni. Nyilvan, lehetne valami minimal configot kernel fejlesztoeknek osszedobni (ha sikerul a gcc-sekbol minimalis hajlandosagot kisajtolni), ami a problemak 98%-at megfogja, de akkor megint ott leszunk hogy az a 2% fog szopni aki nem common hw-n hasznalja a kernelt.

Random disztro megoldja, igen. Nem azt mondom hogy linux-nal ez oriasi problema lesz, sokan hasznaljak, azert valoszinuleg hamar kiderul ha valami nem oke, aztan ha valakinel megse oke, fel perc google es megtalalja a megoldast. Az ilyen kisebb projektek, amik sokszor be se kerulnek semmilyen disztro csomagtarolojaba, na ott szoktak ezek bajosak lenni, mert ott nem mondhatod a usernek hogy szedje le a nem letezo binarist, meg google se biztos fog ertelmes valaszt adni, hogy a random xyz csomag + abc buildrendszer kombinacioban milyen custom flaget kell beadni hogy ne legyen -Werror.

I hate myself, because I'm not open-source.

bar nem ismerem a gcc development workflow-t, de nem hiszem hogy a fejleszto reggel kikel az agybol es kommitol egy warningolo ellenorzest. elotte jo esetben atragjak hogy azt most valoban erdemes warningra rakni, a linux fejlesztok kozul meg valszeg olvassa jopar ezeket az emaileket, igy tudnak rola hogy lesz egy warning, esetleg ha szerintuk az nem warning akkor ervelnek ezert. ha megis bekerul egy ilyen warning uzenet akkor meg az valid, es jo lenne ha nem is lenne ilyen a kernelben, igy nekik kell javitani.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Mindez szep es jo, es valoszinuleg tenyleg >0 olyan ember van aki linux es gcc fejlesztesben is valamennyire benne van, de amit mondtam felul hogy pl talalnak egy bugot valamelyik warningban es javitjak, arrol valoszinuleg nem lesz nagyon hosszas levelezes hogy ezt megis miert. Tovabba azert gcc-be egy uj warning felvetel az nem olyan amihez ossze kell hivni a c commitee-t, nem ilyen sok evre elore kitalalt valami. Es akkor itt jon be a

ha megis bekerul egy ilyen warning uzenet akkor meg az valid, es jo lenne ha nem is lenne ilyen a kernelben, igy nekik kell javitani.

Igen, itt az idogep bajom, a mar kireleaselt kernelek ettol nem fognak magikusan megjavulni. Vagy ezentul minden kernel release melle oda fogjak irni hogy pontosan melyik gcc verziokat tamogatnak, se regebbit se ujabbat? Vannak helyek ahol meg 2.6.3x kernel-t futtatnak (bar teny, ok valami hasonlo frissessegu gcc-t is fognak hasznalni), de azert ennel egy fokkal kevesbe durva verziot el tudok kepzelni (kicsit regi kernelen van, mert az uj kernelen valami nem mukodik, viszont gcc-bol meg fennt van neki az uj, mert kel valami szuper c++huszonsok programhoz, vagy akarmi. Nem azt mondom hogy ez a jellemzo, de azert elo tud fordulni.

Amire ki akarok lyukadni, eleg sok kellemetlen tapasztalatom volt mar abbol mert valaki berakott wgy Werror-t, aztan valamelyik disztroban levo gcc-vel meg epp dobott valami warningot. (Aztan hogy rosszabb legyen a helyzet, ugye disztrok meg szeretnek is belepatchelni neha, legyen-e default -fstack-protector meg tarsai, nem tudom warningokkal jatszanak-e ilyet, de nem lepodnek meg.) Nyilvan, a Linux kernelnek nem nagyon van kulso dependencyje, meg nagyon sokan hasznaljak, igy kevesbe valoszinu hogy ebbol baj legyen, de azert nem kizarhato.

I hate myself, because I'm not open-source.

Vagy ezentul minden kernel release melle oda fogjak irni hogy pontosan melyik gcc verziokat tamogatnak, se regebbit se ujabbat?

Ennek lenne értelme, igen. Ha nem is adott MAJOR.MINOR.PATCH verziót, de legalább egy MAJOR.MINOR - MAJOR.MINOR tartományt. A GCC fejlesztőitől meg elvárható lenne, hogy egy új warning bevezetése, vagy egy meglévő warning scopejának növelése minimum a MINOR verzió növelését vonja maga után.

Nem tudom, C/C++ fejlesztésnél mennyire jellemző, hogy különböző projectek különböző verziójú toolchaint követeljenek meg. Magasabb szintű nyelveknél és runtimeoknál ez azért elő szokott fordulni, ezért vannak is rá megoldások. Én azt gondolnám, hogy ezt meg lehet oldani C/C++ projecteknél is.

Ha nem is adott MAJOR.MINOR.PATCH

A gcc verziozasa mostanaban MINOR.PATCH.CONSTANT_0, utobbi 10 evben mindenki elfelejtette hogy mire jo a verzioszam, nem csak a webbrowser fejlesztok :( De igen, az elvarhato hogy patch verzioba uj warning ne keruljon bele, de ha esetleg kiderul hogy egy bug miatt valamelyik warning neha nem warningolt, akkor ezt megjavithatjak?

Nem tudom, C/C++ fejlesztésnél mennyire jellemző, hogy különböző projectek különböző verziójú toolchaint követeljenek meg.

Ceges kornyezetben szokott inkabb ilyen elofordulni, opensource projekteknel nem annyira. Mert hat ugye ha egy szabanynak megfelelo programot irsz, akkor az barmilyen a szabvanyt implementalo compilerrel pontosan ugyan olyan tokeletesen kell mukodjon :) Na de viccet felreteve Pale Moon-t leszamitva most nem tudnek mondani olyan opensource programot amit igy kulonosebben erdekelne melyik verzioju compilered van, azt leszamitva hogy minimum x. Azert a C-nel komolyan veszik a backward compatibilityt (c++-nal mar kevesbe), nem ugy mint python meg rust meg tarsai ahol minden uj release 50000 dolgot eltor, ugyhogy emiatt valoszinuleg amugy is kisebb szukseg van ra. Ha valami nem mukodik egy uj compilerrer, akkor vagy eleve hibas volt a kod, vagy bugos a compiler.

Nyilvan, egy kernel az azert mas kategoria mint egy random userspace cucc, sokkal tobb low level hakolas kell bele, ugyhogy azert itt egy fokkal vallalhatobb hogy kicsit jobban dependel a compileren. Mar az eleve gcc specifikus hogy hogy csinalsz olyan binarist ami igy egy nyers ize, es nem egy ELF vagy PE vagy akarmi amit egy OS be fog tolteni, de azert a libgcc funkcionalitasa legyen meg.

I hate myself, because I'm not open-source.

Teljesen jogosak a kerdesek, amiket felvetsz, es egy valamirevalo projektnek adott mereten belul tudni is kell ezekre valaszolni (es lehetoleg valami erdemi alapokon nyugvo valaszt adni pl. cost/benefit). Majd csiszolni a valaszokat a tapasztalatok es a valtozasok fenyeben. Mert ezek a valaszok jelentosen hozzajarulnak ahhoz, hogy az opensource okoszisztema mennyire lesz integralhato.

Szerkesztve: 2021. 09. 06., h – 12:29

Ezért best practice jobb helyeken, hogy standard fordítót használnak. Jobb hely: Android, BSD, Apple. :)

PS: Köszönjük Drupal, hogy nem sikerült a megfelelő helyre írni a választ.

Azt nem értem, hogy miért kell olyan sz*r kódot írni, ami warningos a fordítási időben.  Az elmúlt 40 év alatt megtanultam, hogy a warning mindig jelent valamit :)  ...és minden IF-nek legyen ELSE ága is :)

Még a -ansi opciót is defaulttá tehetné, akkor lenne igazán nagy borulás :D

(de legalábbis a gnu extension-öket sem kellene benne hagyni)

Nincs ezzel semmi gond. Eddig is Linus döntötte el, hogy mikor kész egy kiadás. Legfeljebb kicsit hosszabb lesz egy időablak - vagy kevesebb commit lesz beemelve adott időablak alatt. Valószínűleg jót tenne a Linuxnak, ha kicsit kevésbé rohannának a kernelfejlesztők.

 

(Közismert legenda, hogy a - ma már DragonflyBSD-s, akkor FreeBSD-fejlesztő - Matthew Dillon bekapcsolt valami assert -> kernel panic jellegű beállítást a 4.x FreeBSD make world-jében, aminek hatására esett-kelt a rendszer, de egy rövid idő után szépen kihullottak a hibák :-) )

Nekem nem nyom a kernelfordítás warningokat, igaz csak lehet azért, mert nem volt bekapcsolva a kijelzése a make scriptben. De igazából ez a warning fetisizmus hülyeség, egy olyan portábilis szoftvernél, mint a Linux kernel, hogy nem tudom hány architektúrán, hányféle fordítóval (gcc, clang), azok rengeteg félre verziójával mind le kell forduljon, ezen a szinten nem kéne a warningoknak túl nagy figyelmet szentelni.

“I didn’t start using Linux so I could have friends.” (Luke Smith, 2019) 🐧

Biztos sok a "felesleges" warning, de van jó pár, ami pl egy újabb szemléletű nyelv alatt már nem warning, hanem fordítási hiba. Azért lennének a warningok, hogy a rossz beidegződéseket, gyakran hibát okozó gyakorlatokat kivezessék és legyen egyfajta kódminőség és egységesség, ami mellett ugyan még bőven lehet hibaforrás, de  talán a lefordított szoftver minőségére is kihat(hat). Egy projekt vezetője, lásd Linus, joggal várja el, hogy minden lehetséges módon (egyik módja a warningok kigyomlálása) törekedjenek a minőségi kódbázisra. Szerintem.

A magam részéről azért tértem át rolling release disztróra, hogy mindig a legújabb fordítókkal dolgozhassak, és ha megjelenik egy új gcc/clang warning azzal én találkozzak először. A warningokat kijavítom, mielőtt még mások találkoznának vele (legalábbis ez a cél). A sok warning azért nem jó, mert a sok szemét között nem veszed észre, ha megjelenik egy újabb, ami tényleg fontos.

Lógok a szeren (K. Frigyes)

Lógok az ereszen (Sz. József)