tech-kern by thread

• Date Index
• Date Index (newest page)
• Old Index

• Is RCU now possible?, Dennis Ferguson
  • Re: Is RCU now possible?, ian007
    • Re: Is RCU now possible?, Dennis Ferguson
      • Re: Is RCU now possible?, Ryota Ozaki
      • Re: Is RCU now possible?, Ian Fink
• Set of 26 potential bugs, Maxime Villard
  • Re: Set of 26 potential bugs, Rich Neswold
    • Re: Set of 26 potential bugs, Maxime Villard
• Interested in working on 'Rewriting Kernfs and Pro, Sanchit Gupta
  • Re: Interested in working on 'Rewriting Kernfs and, Jeff Rizzo
• Making global variables of if.c MPSAFE, Ryota Ozaki
  • Re: Making global variables of if.c MPSAFE, Dennis Ferguson
    • Re: Making global variables of if.c MPSAFE, Hisashi T Fujinaka
      • Re: Making global variables of if.c MPSAFE, Ryota Ozaki
      • Re: Making global variables of if.c MPSAFE, Hisashi T Fujinaka
    • Re: Making global variables of if.c MPSAFE, Ryota Ozaki
      • Re: Making global variables of if.c MPSAFE, Ryota Ozaki
      • Re: Making global variables of if.c MPSAFE, Dennis Ferguson
      • Re: Making global variables of if.c MPSAFE, Ryota Ozaki
  • struct ifnet and ifaddr handling [was: Re: Making , Mindaugas Rasiukevicius
    • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Mindaugas Rasiukevicius
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Taylor R Campbell
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Taylor R Campbell
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Taylor R Campbell
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Taylor R Campbell
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Taylor R Campbell
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Taylor R Campbell
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Taylor R Campbell
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Taylor R Campbell
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • re: struct ifnet and ifaddr handling [was: Re: Mak, matthew green
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • re: struct ifnet and ifaddr handling [was: Re: Mak, matthew green
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • re: struct ifnet and ifaddr handling [was: Re: Mak, matthew green
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, David Young
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Masao Uebayashi
      • Re: struct ifnet and ifaddr handling [was: Re: Mak, Ryota Ozaki
• fdiscard error cases, David Holland
  • Re: fdiscard error cases, Alan Barrett
• sysctl weirdness on m68k, Izumi Tsutsui
  • Re: sysctl weirdness on m68k, John Klos
    • Re: sysctl weirdness on m68k, Palle Lyckegaard
      • Re: sysctl weirdness on m68k, Izumi Tsutsui
  • Re: sysctl weirdness on m68k, John Klos
• RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
  • Re: RFC: IRQ affinity (aka interrupt routing), Martin Husemann
    • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), David Young
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Thor Lancelot Simon
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
  • Re: RFC: IRQ affinity (aka interrupt routing), Justin Cormack
  • Re: RFC: IRQ affinity (aka interrupt routing), Mindaugas Rasiukevicius
    • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
  • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
    • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Mindaugas Rasiukevicius
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Matt Thomas
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Matt Thomas
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Mindaugas Rasiukevicius
    • Re: RFC: IRQ affinity (aka interrupt routing), Martin Husemann
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Martin Husemann
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Martin Husemann
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Manuel Bouyer
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Manuel Bouyer
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Manuel Bouyer
      • Re: RFC: IRQ affinity (aka interrupt routing), Thor Lancelot Simon
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Thor Lancelot Simon
    • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Mindaugas Rasiukevicius
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
      • Re: RFC: IRQ affinity (aka interrupt routing), Kengo NAKAHARA
• Marvell 88SE9230 AHCI?, Thor Lancelot Simon
  • Re: Marvell 88SE9230 AHCI?, Manuel Bouyer
    • Re: Marvell 88SE9230 AHCI?, Masanobu SAITOH
      • Re: Marvell 88SE9230 AHCI?, Masanobu SAITOH
      • Re: Marvell 88SE9230 AHCI?, Masanobu SAITOH
      • Re: Marvell 88SE9230 AHCI?, Thor Lancelot Simon
      • Re: Marvell 88SE9230 AHCI?, Matt Thomas
• More detailed build infomation in kernels, Alan Barrett
  • Re: More detailed build infomation in kernels, Christos Zoulas
  • Re: More detailed build infomation in kernels, Taylor R Campbell
• task queues, Taylor R Campbell
  • Re: task queues, Mindaugas Rasiukevicius
    • Re: task queues, Martin Husemann
      • Re: task queues, Taylor R Campbell
    • Re: task queues, Taylor R Campbell
• pserialized reader/writer locks, Taylor R Campbell
  • Re: pserialized reader/writer locks, Mindaugas Rasiukevicius
    • Re: pserialized reader/writer locks, Taylor R Campbell
      • Re: pserialized reader/writer locks, Mindaugas Rasiukevicius
      • Re: pserialized reader/writer locks, Taylor R Campbell
• removing mappings of uvm objects or device pages, Taylor R Campbell
• uvm objects and bus_dma, Taylor R Campbell
• how to properly enable modules for pci devices?, Christoph Badura
• Spam Good-day, Ms . Zou
• icache sync private rump component, Alexander Nasonov
  • Re: icache sync private rump component, Justin Cormack
    • Re: icache sync private rump component, Alexander Nasonov
      • Re: icache sync private rump component, Alexander Nasonov
      • Re: icache sync private rump component, Alexander Nasonov
    • Re: icache sync private rump component, Alexander Nasonov
  • Re: icache sync private rump component, Greg Troxel
    • Re: icache sync private rump component, Alexander Nasonov
      • Re: icache sync private rump component, Greg Troxel
      • Re: icache sync private rump component, Alexander Nasonov
  • Re: icache sync private rump component, Matt Thomas
    • Re: icache sync private rump component, Alexander Nasonov
• KMEM_REDZONE on DIAGNOSTIC, Maxime Villard
• troubles with an USB touch screen, Manuel Bouyer
  • Re: troubles with an USB touch screen, Yorick Hardy
    • Re: troubles with an USB touch screen, Manuel Bouyer
• msdosfs and small sectors, Maxime Villard
  • Re: msdosfs and small sectors, Martin Husemann
    • Re: msdosfs and small sectors, Maxime Villard
      • Re: msdosfs and small sectors, Greg Troxel
      • re: msdosfs and small sectors, matthew green
      • Re: msdosfs and small sectors, Maxime Villard
      • Re: msdosfs and small sectors, Greg Troxel
      • Re: msdosfs and small sectors, David Holland
      • Re: msdosfs and small sectors, Maxime Villard
      • Re: msdosfs and small sectors, David Laight
      • Re: msdosfs and small sectors, Rhialto
      • Re: msdosfs and small sectors, Roger Brooks
• Problem in msdosfs_moutfs, Gerald_Lee
  • Re: Problem in msdosfs_moutfs, Christos Zoulas
    • Re: Problem in msdosfs_moutfs, Matthias Drochner
      • Re: Problem in msdosfs_moutfs, Stephen Borrill
      • Re: Problem in msdosfs_moutfs, Maxime Villard
• crunchgen and c++, Frank Zerangue
  • Re: crunchgen and c++, David Laight
• libpciaccess support for has_kernel_driver method, matthew green
  • Re: libpciaccess support for has_kernel_driver met, Martin Husemann
  • Re: libpciaccess support for has_kernel_driver met, Christos Zoulas
    • re: libpciaccess support for has_kernel_driver met, matthew green
• lua: pending patches, Lourival Vieira Neto
  • Re: lua: pending patches, Alexander Nasonov
    • Re: lua: pending patches, Lourival Vieira Neto
      • Re: lua: pending patches, Marc Balmer
• fsck_lfs, David Holland
  • Re: fsck_lfs, Konrad Schroder
    • Re: fsck_lfs, Eduardo Horvath