Merge tag 'net-next-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-nextgrafted

Pull networking updates from Jakub Kicinski:
 "Core:

   - Add dedicated kmem_cache for typical/small skb->head, avoid having
     to access struct page at kfree time, and improve memory use.

   - Introduce sysctl to set default RPS configuration for new netdevs.

   - Define Netlink protocol specification format which can be used to
     describe messages used by each family and auto-generate parsers.
     Add tools for generating kernel data structures and uAPI headers.

   - Expose all net/core sysctls inside netns.

   - Remove 4s sleep in netpoll if carrier is instantly detected on
     boot.

   - Add configurable limit of MDB entries per port, and port-vlan.

   - Continue populating drop reasons throughout the stack.

   - Retire a handful of legacy Qdiscs and classifiers.

  Protocols:

   - Support IPv4 big TCP (TSO frames larger than 64kB).

   - Add IP_LOCAL_PORT_RANGE socket option, to control local port range
     on socket by socket basis.

   - Track and report in procfs number of MPTCP sockets used.

   - Support mixing IPv4 and IPv6 flows in the in-kernel MPTCP path
     manager.

   - IPv6: don't check net.ipv6.route.max_size and rely on garbage
     collection to free memory (similarly to IPv4).

   - Support Penultimate Segment Pop (PSP) flavor in SRv6 (RFC8986).

   - ICMP: add per-rate limit counters.

   - Add support for user scanning requests in ieee802154.

   - Remove static WEP support.

   - Support minimal Wi-Fi 7 Extremely High Throughput (EHT) rate
     reporting.

   - WiFi 7 EHT channel puncturing support (client & AP).

  BPF:

   - Add a rbtree data structure following the "next-gen data structure"
     precedent set by recently added linked list, that is, by using
     kfunc + kptr instead of adding a new BPF map type.

   - Expose XDP hints via kfuncs with initial support for RX hash and
     timestamp metadata.

   - Add BPF_F_NO_TUNNEL_KEY extension to bpf_skb_set_tunnel_key to
     better support decap on GRE tunnel devices not operating in collect
     metadata.

   - Improve x86 JIT's codegen for PROBE_MEM runtime error checks.

   - Remove the need for trace_printk_lock for bpf_trace_printk and
     bpf_trace_vprintk helpers.

   - Extend libbpf's bpf_tracing.h support for tracing arguments of
     kprobes/uprobes and syscall as a special case.

   - Significantly reduce the search time for module symbols by
     livepatch and BPF.

   - Enable cpumasks to be used as kptrs, which is useful for tracing
     programs tracking which tasks end up running on which CPUs in
     different time intervals.

   - Add support for BPF trampoline on s390x and riscv64.

   - Add capability to export the XDP features supported by the NIC.

   - Add __bpf_kfunc tag for marking kernel functions as kfuncs.

   - Add cgroup.memory=nobpf kernel parameter option to disable BPF
     memory accounting for container environments.

  Netfilter:

   - Remove the CLUSTERIP target. It has been marked as obsolete for
     years, and we still have WARN splats wrt races of the out-of-band
     /proc interface installed by this target.

   - Add 'destroy' commands to nf_tables. They are identical to the
     existing 'delete' commands, but do not return an error if the
     referenced object (set, chain, rule...) did not exist.

  Driver API:

   - Improve cpumask_local_spread() locality to help NICs set the right
     IRQ affinity on AMD platforms.

   - Separate C22 and C45 MDIO bus transactions more clearly.

   - Introduce new DCB table to control DSCP rewrite on egress.

   - Support configuration of Physical Layer Collision Avoidance (PLCA)
     Reconciliation Sublayer (RS) (802.3cg-2019). Modern version of
     shared medium Ethernet.

   - Support for MAC Merge layer (IEEE 802.3-2018 clause 99). Allowing
     preemption of low priority frames by high priority frames.

   - Add support for controlling MACSec offload using netlink SET.

   - Rework devlink instance refcounts to allow registration and
     de-registration under the instance lock. Split the code into
     multiple files, drop some of the unnecessarily granular locks and
     factor out common parts of netlink operation handling.

   - Add TX frame aggregation parameters (for USB drivers).

   - Add a new attr TCA_EXT_WARN_MSG to report TC (offload) warning
     messages with notifications for debug.

   - Allow offloading of UDP NEW connections via act_ct.

   - Add support for per action HW stats in TC.

   - Support hardware miss to TC action (continue processing in SW from
     a specific point in the action chain).

   - Warn if old Wireless Extension user space interface is used with
     modern cfg80211/mac80211 drivers. Do not support Wireless
     Extensions for Wi-Fi 7 devices at all. Everyone should switch to
     using nl80211 interface instead.

   - Improve the CAN bit timing configuration. Use extack to return
     error messages directly to user space, update the SJW handling,
     including the definition of a new default value that will benefit
     CAN-FD controllers, by increasing their oscillator tolerance.

  New hardware / drivers:

   - Ethernet:
      - nVidia BlueField-3 support (control traffic driver)
      - Ethernet support for imx93 SoCs
      - Motorcomm yt8531 gigabit Ethernet PHY
      - onsemi NCN26000 10BASE-T1S PHY (with support for PLCA)
      - Microchip LAN8841 PHY (incl. cable diagnostics and PTP)
      - Amlogic gxl MDIO mux

   - WiFi:
      - RealTek RTL8188EU (rtl8xxxu)
      - Qualcomm Wi-Fi 7 devices (ath12k)

   - CAN:
      - Renesas R-Car V4H

  Drivers:

   - Bluetooth:
      - Set Per Platform Antenna Gain (PPAG) for Intel controllers.

   - Ethernet NICs:
      - Intel (1G, igc):
         - support TSN / Qbv / packet scheduling features of i226 model
      - Intel (100G, ice):
         - use GNSS subsystem instead of TTY
         - multi-buffer XDP support
         - extend support for GPIO pins to E823 devices
      - nVidia/Mellanox:
         - update the shared buffer configuration on PFC commands
         - implement PTP adjphase function for HW offset control
         - TC support for Geneve and GRE with VF tunnel offload
         - more efficient crypto key management method
         - multi-port eswitch support
      - Netronome/Corigine:
         - add DCB IEEE support
         - support IPsec offloading for NFP3800
      - Freescale/NXP (enetc):
         - support XDP_REDIRECT for XDP non-linear buffers
         - improve reconfig, avoid link flap and waiting for idle
         - support MAC Merge layer
      - Other NICs:
         - sfc/ef100: add basic devlink support for ef100
         - ionic: rx_push mode operation (writing descriptors via MMIO)
         - bnxt: use the auxiliary bus abstraction for RDMA
         - r8169: disable ASPM and reset bus in case of tx timeout
         - cpsw: support QSGMII mode for J721e CPSW9G
         - cpts: support pulse-per-second output
         - ngbe: add an mdio bus driver
         - usbnet: optimize usbnet_bh() by avoiding unnecessary queuing
         - r8152: handle devices with FW with NCM support
         - amd-xgbe: support 10Mbps, 2.5GbE speeds and rx-adaptation
         - virtio-net: support multi buffer XDP
         - virtio/vsock: replace virtio_vsock_pkt with sk_buff
         - tsnep: XDP support

   - Ethernet high-speed switches:
      - nVidia/Mellanox (mlxsw):
         - add support for latency TLV (in FW control messages)
      - Microchip (sparx5):
         - separate explicit and implicit traffic forwarding rules, make
           the implicit rules always active
         - add support for egress DSCP rewrite
         - IS0 VCAP support (Ingress Classification)
         - IS2 VCAP filters (protos, L3 addrs, L4 ports, flags, ToS
           etc.)
         - ES2 VCAP support (Egress Access Control)
         - support for Per-Stream Filtering and Policing (802.1Q,
           8.6.5.1)

   - Ethernet embedded switches:
      - Marvell (mv88e6xxx):
         - add MAB (port auth) offload support
         - enable PTP receive for mv88e6390
      - NXP (ocelot):
         - support MAC Merge layer
         - support for the the vsc7512 internal copper phys
      - Microchip:
         - lan9303: convert to PHYLINK
         - lan966x: support TC flower filter statistics
         - lan937x: PTP support for KSZ9563/KSZ8563 and LAN937x
         - lan937x: support Credit Based Shaper configuration
         - ksz9477: support Energy Efficient Ethernet
      - other:
         - qca8k: convert to regmap read/write API, use bulk operations
         - rswitch: Improve TX timestamp accuracy

   - Intel WiFi (iwlwifi):
      - EHT (Wi-Fi 7) rate reporting
      - STEP equalizer support: transfer some STEP (connection to radio
        on platforms with integrated wifi) related parameters from the
        BIOS to the firmware.

   - Qualcomm 802.11ax WiFi (ath11k):
      - IPQ5018 support
      - Fine Timing Measurement (FTM) responder role support
      - channel 177 support

   - MediaTek WiFi (mt76):
      - per-PHY LED support
      - mt7996: EHT (Wi-Fi 7) support
      - Wireless Ethernet Dispatch (WED) reset support
      - switch to using page pool allocator

   - RealTek WiFi (rtw89):
      - support new version of Bluetooth co-existance

   - Mobile:
      - rmnet: support TX aggregation"

* tag 'net-next-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1872 commits)
  page_pool: add a comment explaining the fragment counter usage
  net: ethtool: fix __ethtool_dev_mm_supported() implementation
  ethtool: pse-pd: Fix double word in comments
  xsk: add linux/vmalloc.h to xsk.c
  sefltests: netdevsim: wait for devlink instance after netns removal
  selftest: fib_tests: Always cleanup before exit
  net/mlx5e: Align IPsec ASO result memory to be as required by hardware
  net/mlx5e: TC, Set CT miss to the specific ct action instance
  net/mlx5e: Rename CHAIN_TO_REG to MAPPED_OBJ_TO_REG
  net/mlx5: Refactor tc miss handling to a single function
  net/mlx5: Kconfig: Make tc offload depend on tc skb extension
  net/sched: flower: Support hardware miss to tc action
  net/sched: flower: Move filter handle initialization earlier
  net/sched: cls_api: Support hardware miss to tc action
  net/sched: Rename user cookie and act cookie
  sfc: fix builds without CONFIG_RTC_LIB
  sfc: clean up some inconsistent indentings
  net/mlx4_en: Introduce flexible array to silence overflow warning
  net: lan966x: Fix possible deadlock inside PTP
  net/ulp: Remove redundant ->clone() test in inet_clone_ulp().
  ...

1 files changed, 446 insertions, 0 deletions

diff --git a/Documentation/translations/it_IT/process/4.Coding.rst b/Documentation/translations/it_IT/process/4.Coding.rst
new file mode 100644
index 000000000..54fd255b7
--- /dev/null
+++ b/Documentation/translations/it_IT/process/4.Coding.rst
@@ -0,0 +1,446 @@
+.. include:: ../disclaimer-ita.rst
+
+:Original: :ref:`Documentation/process/4.Coding.rst <development_coding>`
+:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
+
+.. _it_development_coding:
+
+Scrivere codice corretto
+========================
+
+Nonostante ci sia molto da dire sul processo di creazione, sulla sua solidità
+e sul suo orientamento alla comunità, la prova di ogni progetto di sviluppo
+del kernel si trova nel codice stesso.  È il codice che sarà esaminato dagli
+altri sviluppatori ed inserito (o no) nel ramo principale. Quindi è la
+qualità di questo codice che determinerà il successo finale del progetto.
+
+Questa sezione esaminerà il processo di codifica.  Inizieremo con uno sguardo
+sulle diverse casistiche nelle quali gli sviluppatori kernel possono
+sbagliare.  Poi, l'attenzione si sposterà verso "il fare le cose
+correttamente" e sugli strumenti che possono essere utili in questa missione.
+
+Trappole
+--------
+
+Lo stile del codice
+*******************
+
+Il kernel ha da tempo delle norme sullo stile di codifica che sono descritte in
+:ref:`Documentation/translations/it_IT/process/coding-style.rst <codingstyle>`.
+Per la maggior parte del tempo, la politica descritta in quel file è stata
+praticamente informativa.  Ne risulta che ci sia una quantità sostanziale di
+codice nel kernel che non rispetta le linee guida relative allo stile.
+La presenza di quel codice conduce a due distinti pericoli per gli
+sviluppatori kernel.
+
+Il primo di questi è credere che gli standard di codifica del kernel
+non sono importanti e possono non essere applicati.  La verità è che
+aggiungere nuovo codice al kernel è davvero difficile se questo non
+rispetta le norme; molti sviluppatori richiederanno che il codice sia
+riformulato prima che anche solo lo revisionino.  Una base di codice larga
+quanto il kernel richiede una certa uniformità, in modo da rendere possibile
+per gli sviluppatori una comprensione veloce di ogni sua parte.  Non ci sono,
+quindi, più spazi per un codice formattato alla carlona.
+
+Occasionalmente, lo stile di codifica del kernel andrà in conflitto con lo
+stile richiesto da un datore di lavoro.  In alcuni casi, lo stile del kernel
+dovrà prevalere prima che il codice venga inserito.  Mettere il codice
+all'interno del kernel significa rinunciare a un certo grado di controllo
+in differenti modi - incluso il controllo sul come formattare il codice.
+
+L’altra trappola è quella di pensare che il codice già presente nel kernel
+abbia urgentemente bisogno di essere sistemato.  Gli sviluppatori potrebbero
+iniziare a generare patch che correggono lo stile come modo per prendere
+famigliarità con il processo, o come modo per inserire i propri nomi nei
+changelog del kernel – o entrambe.  La comunità di sviluppo vede un attività
+di codifica puramente correttiva come "rumore"; queste attività riceveranno
+una fredda accoglienza.  Di conseguenza è meglio evitare questo tipo di patch.
+Mentre si lavora su un pezzo di codice è normale correggerne anche lo stile,
+ma le modifiche di stile non dovrebbero essere fatte fini a se stesse.
+
+Il documento sullo stile del codice non dovrebbe essere letto come una legge
+assoluta che non può mai essere trasgredita.  Se c’è un a buona ragione
+(per esempio, una linea che diviene poco leggibile se divisa per rientrare
+nel limite di 80 colonne), fatelo e basta.
+
+Notate che potete utilizzare lo strumento “clang-format” per aiutarvi con
+le regole, per una riformattazione automatica e veloce del vostro codice
+e per revisionare interi file per individuare errori nello stile di codifica,
+refusi e possibili miglioramenti.  Inoltre è utile anche per classificare gli
+``#includes``, per allineare variabili/macro, per testi derivati ed altri
+compiti del genere.  Consultate il file
+:ref:`Documentation/translations/it_IT/process/clang-format.rst <clangformat>`
+per maggiori dettagli
+
+
+Livelli di astrazione
+*********************
+
+
+I professori di Informatica insegnano ai propri studenti a fare ampio uso dei
+livelli di astrazione nel nome della flessibilità e del nascondere informazioni.
+Certo il kernel fa un grande uso dell'astrazione; nessun progetto con milioni
+di righe di codice potrebbe fare altrimenti e sopravvivere.  Ma l'esperienza
+ha dimostrato che un'eccessiva o prematura astrazione può rivelarsi dannosa
+al pari di una prematura ottimizzazione.  L'astrazione dovrebbe essere usata
+fino al livello necessario e non oltre.
+
+Ad un livello base, considerate una funzione che ha un argomento che viene
+sempre impostato a zero da tutti i chiamanti.  Uno potrebbe mantenere
+quell'argomento nell'eventualità qualcuno volesse sfruttare la flessibilità
+offerta.  In ogni caso, tuttavia, ci sono buone possibilità che il codice
+che va ad implementare questo argomento aggiuntivo, sia stato rotto in maniera
+sottile, in un modo che non è mai stato notato - perché non è mai stato usato.
+Oppure, quando sorge la necessità di avere più flessibilità, questo argomento
+non la fornisce in maniera soddisfacente.  Gli sviluppatori di Kernel,
+sottopongono costantemente patch che vanno a rimuovere gli argomenti
+inutilizzate; anche se, in generale, non avrebbero dovuto essere aggiunti.
+
+I livelli di astrazione che nascondono l'accesso all'hardware -
+spesso per poter usare dei driver su diversi sistemi operativi - vengono
+particolarmente disapprovati.  Tali livelli oscurano il codice e possono
+peggiorare le prestazioni; essi non appartengono al kernel Linux.
+
+D'altro canto, se vi ritrovate a dover copiare una quantità significativa di
+codice proveniente da un altro sottosistema del kernel, è tempo di chiedersi
+se, in effetti, non avrebbe più senso togliere parte di quel codice e metterlo
+in una libreria separata o di implementare quella funzionalità ad un livello
+più elevato.  Non c'è utilità nel replicare lo stesso codice per tutto
+il kernel.
+
+
+#ifdef e l'uso del preprocessore in generale
+********************************************
+
+Il preprocessore C sembra essere una fonte di attrazione per qualche
+programmatore C, che ci vede una via per ottenere una grande flessibilità
+all'interno di un file sorgente.  Ma il preprocessore non è scritto in C,
+e un suo massiccio impiego conduce a un codice che è molto più difficile
+da leggere per gli altri e che rende più difficile il lavoro di verifica del
+compilatore.  L'uso eccessivo del preprocessore è praticamente sempre il segno
+di un codice che necessita di un certo lavoro di pulizia.
+
+La compilazione condizionata con #ifdef è, in effetti, un potente strumento,
+ed esso viene usato all'interno del kernel.  Ma esiste un piccolo desiderio:
+quello di vedere il codice coperto solo da una leggera spolverata di
+blocchi #ifdef.  Come regola generale, quando possibile, l'uso di #ifdef
+dovrebbe essere confinato nei file d'intestazione.  Il codice compilato
+condizionatamente può essere confinato a funzioni tali che, nel caso in cui
+il codice non deve essere presente, diventano vuote.  Il compilatore poi
+ottimizzerà la chiamata alla funzione vuota rimuovendola.  Il risultato è
+un codice molto più pulito, più facile da seguire.
+
+Le macro del preprocessore C presentano una serie di pericoli, inclusi
+valutazioni multiple di espressioni che hanno effetti collaterali e non
+garantiscono una sicurezza rispetto ai tipi.  Se siete tentati dal definire
+una macro, considerate l'idea di creare invece una funzione inline.  Il codice
+che ne risulterà sarà lo stesso, ma le funzioni inline sono più leggibili,
+non considerano i propri argomenti più volte, e permettono al compilatore di
+effettuare controlli sul tipo degli argomenti e del valore di ritorno.
+
+
+Funzioni inline
+***************
+
+Comunque, anche le funzioni inline hanno i loro pericoli.  I programmatori
+potrebbero innamorarsi dell'efficienza percepita derivata dalla rimozione
+di una chiamata a funzione.  Queste funzioni, tuttavia, possono ridurre le
+prestazioni.  Dato che il loro codice viene replicato ovunque vi sia una
+chiamata ad esse, si finisce per gonfiare le dimensioni del kernel compilato.
+Questi, a turno, creano pressione sulla memoria cache del processore, e questo
+può causare rallentamenti importanti.  Le funzioni inline, di norma, dovrebbero
+essere piccole e usate raramente.  Il costo di una chiamata a funzione, dopo
+tutto, non è così alto; la creazione di molte funzioni inline è il classico
+esempio di un'ottimizzazione prematura.
+
+In generale, i programmatori del kernel ignorano gli effetti della cache a
+loro rischio e pericolo.  Il classico compromesso tempo/spazio teorizzato
+all'inizio delle lezioni sulle strutture dati spesso non si applica
+all'hardware moderno.  Lo spazio *è* tempo, in questo senso un programma
+più grande sarà più lento rispetto ad uno più compatto.
+
+I compilatori più recenti hanno preso un ruolo attivo nel decidere se
+una data funzione deve essere resa inline oppure no.  Quindi l'uso
+indiscriminato della parola chiave "inline" potrebbe non essere non solo
+eccessivo, ma anche irrilevante.
+
+Sincronizzazione
+****************
+
+Nel maggio 2006, il sistema di rete "Devicescape" fu rilasciato in pompa magna
+sotto la licenza GPL e reso disponibile per la sua inclusione nella ramo
+principale del kernel.  Questa donazione fu una notizia bene accolta;
+il supporto per le reti senza fili era considerata, nel migliore dei casi,
+al di sotto degli standard; il sistema Deviscape offrì la promessa di una
+risoluzione a tale situazione.  Tuttavia, questo codice non fu inserito nel
+ramo principale fino al giugno del 2007 (2.6.22). Cosa accadde?
+
+Quel codice mostrava numerosi segnali di uno sviluppo in azienda avvenuto
+a porte chiuse.  Ma in particolare, un grosso problema fu che non fu
+progettato per girare in un sistema multiprocessore.  Prima che questo
+sistema di rete (ora chiamato mac80211) potesse essere inserito, fu necessario
+un lavoro sugli schemi di sincronizzazione.
+
+Una volta, il codice del kernel Linux poteva essere sviluppato senza pensare
+ai problemi di concorrenza presenti nei sistemi multiprocessore.  Ora,
+comunque, questo documento è stato scritto su di un portatile dual-core.
+Persino su sistemi a singolo processore, il lavoro svolto per incrementare
+la capacità di risposta aumenterà il livello di concorrenza interno al kernel.
+I giorni nei quali il codice poteva essere scritto senza pensare alla
+sincronizzazione sono da passati tempo.
+
+Ogni risorsa (strutture dati, registri hardware, etc.) ai quali si potrebbe
+avere accesso simultaneo da più di un thread deve essere sincronizzato.  Il
+nuovo codice dovrebbe essere scritto avendo tale accortezza in testa;
+riadattare la sincronizzazione a posteriori è un compito molto più difficile.
+Gli sviluppatori del kernel dovrebbero prendersi il tempo di comprendere bene
+le primitive di sincronizzazione, in modo da sceglier lo strumento corretto
+per eseguire un compito.  Il codice che presenta una mancanza di attenzione
+alla concorrenza avrà un percorso difficile all'interno del ramo principale.
+
+Regressioni
+***********
+
+Vale la pena menzionare un ultimo pericolo: potrebbe rivelarsi accattivante
+l'idea di eseguire un cambiamento (che potrebbe portare a grandi
+miglioramenti) che porterà ad alcune rotture per gli utenti esistenti.
+Questa tipologia di cambiamento è chiamata "regressione", e le regressioni son
+diventate mal viste nel ramo principale del kernel.  Con alcune eccezioni,
+i cambiamenti che causano regressioni saranno fermati se quest'ultime non
+potranno essere corrette in tempo utile.  È molto meglio quindi evitare
+la regressione fin dall'inizio.
+
+Spesso si è argomentato che una regressione può essere giustificata se essa
+porta risolve più problemi di quanti non ne crei.  Perché, dunque, non fare
+un cambiamento se questo porta a nuove funzionalità a dieci sistemi per
+ognuno dei quali esso determina una rottura?  La migliore risposta a questa
+domanda ci è stata fornita da Linus nel luglio 2007:
+
+::
+   Dunque, noi non sistemiamo bachi introducendo nuovi problemi. Quella
+   via nasconde insidie, e nessuno può sapere del tutto se state facendo
+   dei progressi reali. Sono due passi avanti e uno indietro, oppure
+   un passo avanti e due indietro?
+
+(http://lwn.net/Articles/243460/).
+
+Una particolare tipologia di regressione mal vista consiste in una qualsiasi
+sorta di modifica all'ABI dello spazio utente.  Una volta che un'interfaccia
+viene esportata verso lo spazio utente, dev'essere supportata all'infinito.
+Questo fatto rende la creazione di interfacce per lo spazio utente
+particolarmente complicato: dato che non possono venir cambiate introducendo
+incompatibilità, esse devono essere fatte bene al primo colpo.  Per questa
+ragione sono sempre richieste: ampie riflessioni, documentazione chiara e
+ampie revisioni dell'interfaccia verso lo spazio utente.
+
+
+Strumenti di verifica del codice
+--------------------------------
+Almeno per ora la scrittura di codice priva di errori resta un ideale
+irraggiungibile ai più.  Quello che speriamo di poter fare, tuttavia, è
+trovare e correggere molti di questi errori prima che il codice entri nel
+ramo principale del kernel.  A tal scopo gli sviluppatori del kernel devono
+mettere insieme una schiera impressionante di strumenti che possano
+localizzare automaticamente un'ampia varietà di problemi.  Qualsiasi problema
+trovato dal computer è un problema che non affliggerà l'utente in seguito,
+ne consegue che gli strumenti automatici dovrebbero essere impiegati ovunque
+possibile.
+
+Il primo passo consiste semplicemente nel fare attenzione agli avvertimenti
+proveniente dal compilatore.  Versioni moderne di gcc possono individuare
+(e segnalare) un gran numero di potenziali errori.  Molto spesso, questi
+avvertimenti indicano problemi reali.  Di regola, il codice inviato per la
+revisione non dovrebbe produrre nessun avvertimento da parte del compilatore.
+Per mettere a tacere gli avvertimenti, cercate di comprenderne le cause reali
+e cercate di evitare le "riparazioni" che fan sparire l'avvertimento senza
+però averne trovato la causa.
+
+Tenete a mente che non tutti gli avvertimenti sono disabilitati di default.
+Costruite il kernel con "make KCFLAGS=-W" per ottenerli tutti.
+
+Il kernel fornisce differenti opzioni che abilitano funzionalità di debugging;
+molti di queste sono trovano all'interno del sotto menu "kernel hacking".
+La maggior parte di queste opzioni possono essere attivate per qualsiasi
+kernel utilizzato per lo sviluppo o a scopo di test.  In particolare dovreste
+attivare:
+
+ - FRAME_WARN per ottenere degli avvertimenti su stack frame più
+   grandi di un dato valore.  Il risultato generato da questi
+   avvertimenti può risultare verboso, ma non bisogna preoccuparsi per
+   gli avvertimenti provenienti da altre parti del kernel.
+
+ - DEBUG_OBJECTS aggiungerà un codice per tracciare il ciclo di vita di
+   diversi oggetti creati dal kernel e avvisa quando qualcosa viene eseguito
+   fuori controllo.  Se state aggiungendo un sottosistema che crea (ed
+   esporta) oggetti complessi propri, considerate l'aggiunta di un supporto
+   al debugging dell'oggetto.
+
+ - DEBUG_SLAB può trovare svariati errori di uso e di allocazione di memoria;
+   esso dovrebbe esser usato dalla maggior parte dei kernel di sviluppo.
+
+ - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP, e DEBUG_MUTEXES troveranno un certo
+   numero di errori comuni di sincronizzazione.
+
+Esistono ancora delle altre opzioni di debugging, di alcune di esse
+discuteremo qui sotto.  Alcune di esse hanno un forte impatto e non dovrebbero
+essere usate tutte le volte.  Ma qualche volta il tempo speso nell'capire
+le opzioni disponibili porterà ad un risparmio di tempo nel breve termine.
+
+Uno degli strumenti di debugging più tosti è il *locking checker*, o
+"lockdep".  Questo strumento traccerà qualsiasi acquisizione e rilascio di
+ogni *lock* (spinlock o mutex) nel sistema, l'ordine con il quale i *lock*
+sono acquisiti in relazione l'uno con l'altro, l'ambiente corrente di
+interruzione, eccetera.  Inoltre esso può assicurare che i *lock* vengano
+acquisiti sempre nello stesso ordine, che le stesse assunzioni sulle
+interruzioni si applichino in tutte le occasioni, e così via.  In altre parole,
+lockdep può scovare diversi scenari nei quali il sistema potrebbe, in rari
+casi, trovarsi in stallo.  Questa tipologia di problema può essere grave
+(sia per gli sviluppatori che per gli utenti) in un sistema in uso; lockdep
+permette di trovare tali problemi automaticamente e in anticipo.
+
+In qualità di programmatore kernel diligente, senza dubbio, dovrete controllare
+il valore di ritorno di ogni operazione (come l'allocazione della memoria)
+poiché esso potrebbe fallire.  Il nocciolo della questione è che i percorsi
+di gestione degli errori, con grande probabilità, non sono mai stati
+collaudati del tutto.  Il codice collaudato tende ad essere codice bacato;
+potrete quindi essere più a vostro agio con il vostro codice se tutti questi
+percorsi fossero stati verificati un po' di volte.
+
+Il kernel fornisce un framework per l'inserimento di fallimenti che fa
+esattamente al caso, specialmente dove sono coinvolte allocazioni di memoria.
+Con l'opzione per l'inserimento dei fallimenti abilitata, una certa percentuale
+di allocazione di memoria sarà destinata al fallimento; questi fallimenti
+possono essere ridotti ad uno specifico pezzo di codice.  Procedere con
+l'inserimento dei fallimenti attivo permette al programmatore di verificare
+come il codice risponde quando le cose vanno male.  Consultate:
+Documentation/fault-injection/fault-injection.rst per avere maggiori
+informazioni su come utilizzare questo strumento.
+
+Altre tipologie di errori possono essere riscontrati con lo strumento di
+analisi statica "sparse".  Con Sparse, il programmatore può essere avvisato
+circa la confusione tra gli indirizzi dello spazio utente e dello spazio
+kernel, un miscuglio fra quantità big-endian e little-endian, il passaggio
+di un valore intero dove ci sia aspetta un gruppo di flag, e così via.
+Sparse deve essere installato separatamente (se il vostra distribuzione non
+lo prevede, potete trovarlo su https://sparse.wiki.kernel.org/index.php/Main_Page);
+può essere attivato sul codice aggiungendo "C=1" al comando make.
+
+Lo strumento "Coccinelle" (http://coccinelle.lip6.fr/) è in grado di trovare
+una vasta varietà di potenziali problemi di codifica; e può inoltre proporre
+soluzioni per risolverli.  Un buon numero di "patch semantiche" per il kernel
+sono state preparate nella cartella scripts/coccinelle; utilizzando
+"make coccicheck" esso percorrerà tali patch semantiche e farà rapporto su
+qualsiasi problema trovato.  Per maggiori informazioni, consultate
+:ref:`Documentation/dev-tools/coccinelle.rst <devtools_coccinelle>`.
+
+Altri errori di portabilità sono meglio scovati compilando il vostro codice
+per altre architetture.  Se non vi accade di avere un sistema S/390 o una
+scheda di sviluppo Blackfin sotto mano, potete comunque continuare la fase
+di compilazione.  Un vasto numero di cross-compilatori per x86 possono
+essere trovati al sito:
+
+	http://www.kernel.org/pub/tools/crosstool/
+
+Il tempo impiegato nell'installare e usare questi compilatori sarà d'aiuto
+nell'evitare situazioni imbarazzanti nel futuro.
+
+
+Documentazione
+--------------
+
+La documentazione è spesso stata più un'eccezione che una regola nello
+sviluppo del kernel.  Nonostante questo, un'adeguata documentazione aiuterà
+a facilitare l'inserimento di nuovo codice nel kernel, rende la vita più
+facile per gli altri sviluppatori e sarà utile per i vostri utenti.  In molti
+casi, la documentazione è divenuta sostanzialmente obbligatoria.
+
+La prima parte di documentazione per qualsiasi patch è il suo changelog.
+Questi dovrebbero descrivere le problematiche risolte, la tipologia di
+soluzione, le persone che lavorano alla patch, ogni effetto rilevante
+sulle prestazioni e tutto ciò che può servire per la comprensione della
+patch.  Assicuratevi che il changelog dica *perché*, vale la pena aggiungere
+la patch; un numero sorprendente di sviluppatori sbaglia nel fornire tale
+informazione.
+
+Qualsiasi codice che aggiunge una nuova interfaccia in spazio utente - inclusi
+nuovi file in sysfs o /proc - dovrebbe includere la documentazione di tale
+interfaccia così da permette agli sviluppatori dello spazio utente di sapere
+con cosa stanno lavorando.  Consultate: Documentation/ABI/README per avere una
+descrizione di come questi documenti devono essere impostati e quali
+informazioni devono essere fornite.
+
+Il file :ref:`Documentation/translations/it_IT/admin-guide/kernel-parameters.rst <kernelparameters>`
+descrive tutti i parametri di avvio del kernel.  Ogni patch che aggiunga
+nuovi parametri dovrebbe aggiungere nuove voci a questo file.
+
+Ogni nuova configurazione deve essere accompagnata da un testo di supporto
+che spieghi chiaramente le opzioni e spieghi quando l'utente potrebbe volerle
+selezionare.
+
+Per molti sottosistemi le informazioni sull'API interna sono documentate sotto
+forma di commenti formattati in maniera particolare; questi commenti possono
+essere estratti e formattati in differenti modi attraverso lo script
+"kernel-doc".  Se state lavorando all'interno di un sottosistema che ha
+commenti kerneldoc dovreste mantenerli e aggiungerli, in maniera appropriata,
+per le funzioni disponibili esternamente.  Anche in aree che non sono molto
+documentate, non c'è motivo per non aggiungere commenti kerneldoc per il
+futuro; infatti, questa può essere un'attività utile per sviluppatori novizi
+del kernel.  Il formato di questi commenti, assieme alle informazione su come
+creare modelli per kerneldoc, possono essere trovati in
+:ref:`Documentation/translations/it_IT/doc-guide/ <doc_guide>`.
+
+Chiunque legga un ammontare significativo di codice kernel noterà che, spesso,
+i commenti si fanno maggiormente notare per la loro assenza.  Ancora una volta,
+le aspettative verso il nuovo codice sono più alte rispetto al passato;
+inserire codice privo di commenti sarà più difficile.  Detto ciò, va aggiunto
+che non si desiderano commenti prolissi per il codice.  Il codice dovrebbe
+essere, di per sé, leggibile, con dei commenti che spieghino gli aspetti più
+sottili.
+
+Determinate cose dovrebbero essere sempre commentate.  L'uso di barriere
+di memoria dovrebbero essere accompagnate da una riga che spieghi perché sia
+necessaria.  Le regole di sincronizzazione per le strutture dati, generalmente,
+necessitano di una spiegazioni da qualche parte.  Le strutture dati più
+importanti, in generale, hanno bisogno di una documentazione onnicomprensiva.
+Le dipendenze che non sono ovvie tra bit separati di codice dovrebbero essere
+indicate.  Tutto ciò che potrebbe indurre un inserviente del codice a fare
+una "pulizia" incorretta, ha bisogno di un commento che dica perché è stato
+fatto in quel modo.  E così via.
+
+Cambiamenti interni dell'API
+----------------------------
+
+L'interfaccia binaria fornita dal kernel allo spazio utente non può essere
+rotta tranne che in circostanze eccezionali.  L'interfaccia di programmazione
+interna al kernel, invece, è estremamente fluida e può essere modificata al
+bisogno.  Se vi trovate a dover lavorare attorno ad un'API del kernel o
+semplicemente non state utilizzando una funzionalità offerta perché questa
+non rispecchia i vostri bisogni, allora questo potrebbe essere un segno che
+l'API ha bisogno di essere cambiata.  In qualità di sviluppatore del kernel,
+hai il potere di fare questo tipo di modifica.
+
+Ci sono ovviamente alcuni punti da cogliere.  I cambiamenti API possono essere
+fatti, ma devono essere giustificati.  Quindi ogni patch che porta ad una
+modifica dell'API interna dovrebbe essere accompagnata da una descrizione
+della modifica in sé e del perché essa è necessaria.  Questo tipo di
+cambiamenti dovrebbero, inoltre, essere fatti in una patch separata, invece di
+essere sepolti all'interno di una patch più grande.
+
+L'altro punto da cogliere consiste nel fatto che uno sviluppatore che
+modifica l'API deve, in generale, essere responsabile della correzione
+di tutto il codice del kernel che viene rotto per via della sua modifica.
+Per una funzione ampiamente usata, questo compito può condurre letteralmente
+a centinaia o migliaia di modifiche, molte delle quali sono in conflitto con
+il lavoro svolto da altri sviluppatori.  Non c'è bisogno di dire che questo
+può essere un lavoro molto grosso, quindi è meglio essere sicuri che la
+motivazione sia ben solida.  Notate che lo strumento Coccinelle può fornire
+un aiuto con modifiche estese dell'API.
+
+Quando viene fatta una modifica API incompatibile, una persona dovrebbe,
+quando possibile, assicurarsi che quel codice non aggiornato sia trovato
+dal compilatore.  Questo vi aiuterà ad essere sicuri d'avere trovato,
+tutti gli usi di quell'interfaccia.  Inoltre questo avviserà gli sviluppatori
+di codice fuori dal kernel che c'è un cambiamento per il quale è necessario del
+lavoro.  Il supporto al codice fuori dal kernel non è qualcosa di cui gli
+sviluppatori del kernel devono preoccuparsi, ma non dobbiamo nemmeno rendere
+più difficile del necessario la vita agli sviluppatori di questo codice.