Bagikan melalui

Porting driver miniport NDIS ke NetAdapterCx

  • Artikel

Halaman ini menjelaskan cara mengonversi driver miniport NDIS 6.x menjadi driver klien NetAdapterCx.

Untuk informasi umum tentang WDF, silakan tinjau Panduan Pengembangan Driver WDF.

Pengaturan kompilasi

Buka proyek driver miniport NDIS yang ada di Visual Studio dan gunakan langkah-langkah berikut untuk mengonversinya ke proyek KMDF.

  1. Pertama, navigasikan ke Konfigurasi Properti-Driver> Pengaturan-Driver> Model dan verifikasi bahwa Jenis driver diatur ke KMDF, dan bahwa Versi KMDF Mayor dan KMDF Versi Minor keduanya kosong.

  2. Di properti proyek, buka Driver Pengaturan-Network> Adapter Driver dan atur Tautan ke Ekstensi Kelas Adapter Jaringan ke Ya.

    • Jika driver Anda yang dikonversi masih akan memanggil API NDIS, lanjutkan untuk menautkan terhadap ndis.lib.

  3. Hapus makro praprosesor NDIS, seperti NDIS650_MINIPORT=1.

  4. Tambahkan header berikut ke setiap file sumber (atau ke header umum/kompilasi Anda):

    #include <ntddk.h>
#include <wdf.h>
#include <netadaptercx.h>

  5. Tambahkan dekorasi WDF standar ke INF Anda:

    [Yourdriver.Wdf]
KmdfService = Yourdriverservice, Yourdriver.wdfsect

[Yourdriver.wdfsect]
KmdfLibraryVersion = <insert here>

  6. Tambahkan kata kunci jaringan baru yang diperlukan ke bagian NT INF Anda:

    • *Jika Koneksi orPresent

    • *Koneksi ionType

    • *DirectionType

    • *AccessType

    • *HardwareLoopback

      Untuk informasi selengkapnya tentang kata kunci ini dan contohnya, lihat file INF untuk driver klien NetAdapterCx.

Inisialisasi driver

Hapus panggilan ke NdisMRegisterMiniportDriver dari DriverEntry, dan tambahkan yang berikut ini:

WDF_DRIVER_CONFIG_INIT(&config, EvtDriverDeviceAdd);
status = WdfDriverCreate(. . . );
if (!NT_SUCCESS(status)) {
  return status;
}

Jika sudah diatur, hapus bendera WdfDriverInitNoDispatchOverride dari panggilan ke WdfDriverCreate.

DriverUnload adalah rutinitas opsional untuk driver klien jaringan WDF, sehingga Anda dapat menghapusnya jika Anda mau. Jangan panggil NdisMDeregisterMiniportDriver dari DriverUnload.

Inisialisasi perangkat

Selanjutnya, Anda akan mendistribusikan kode dari MiniportInitializeEx ke handler panggilan balik peristiwa WDF yang sesuai, beberapa di antaranya bersifat opsional. Untuk detail tentang urutan panggilan balik, lihat Urutan Power-Up untuk Driver Klien WDF Adapter Jaringan.

Anda akan memanggil metode yang setara dengan NdisMSetMiniportAttributes saat memulai adaptor bersih, tetapi sebelum memanggil NetAdapterStart. Namun, alih-alih memanggil satu rutinitas dengan struktur NDIS_MINIPORT_ADAPTER_ATTRIBUTES generik, driver klien memanggil fungsi yang berbeda untuk mengatur berbagai jenis kemampuan.

Untuk informasi tentang panggilan balik yang perlu Anda berikan dan kapan harus memulai adaptor bersih, lihat Inisialisasi perangkat dan adaptor.

Membaca konfigurasi dari registri

Selanjutnya, ganti panggilan ke NdisOpenConfigurationEx dan fungsi terkait dengan NetConfiguration* metode . Metode ini NetConfiguration* mirip Ndis*Configuration* dengan fungsi, dan Anda tidak perlu merestrukturisasi kode Anda.

Untuk informasi selengkapnya, lihat Mengakses informasi konfigurasi.

Menerima kode kontrol I/O (IOCTL) dari mode pengguna

Baca bagian ini jika driver NDIS Anda memanggil NdisRegisterDeviceEx, rutinitas yang digunakan untuk membuat objek perangkat kontrol (CDO) untuk menerima IOCTL dari mode pengguna.

Berikut adalah dua cara untuk melakukan ini di driver klien jaringan WDF Anda.

Port yang paling mudah adalah membuat objek perangkat kontrol dengan memanggil WdfControlDeviceInitAllocate dari panggilan balik EVT_WDF_DRIVER_DEVICE_ADD klien. Untuk informasi selengkapnya, lihat Menggunakan Objek Perangkat Kontrol.

Namun, solusi yang direkomendasikan adalah membuat antarmuka perangkat, seperti yang dijelaskan dalam Menggunakan Antarmuka Perangkat.

Menyelesaikan inisialisasi perangkat

Pada titik ini di EVT_WDF_DRIVER_DEVICE_ADD, Anda dapat melakukan hal lain yang ingin Anda inisialisasi perangkat Anda, seperti mengalokasikan gangguan.

Menangani pemberitahuan perubahan status daya

Driver klien WDF tidak menerima OID_PNP_SET_POWER untuk perubahan status daya.

Sebagai gantinya, klien WDF mendaftarkan fungsi panggilan balik opsional untuk menerima pemberitahuan perubahan status daya. Untuk gambaran umum, lihat Mendukung PnP dan Manajemen Daya di Driver Fungsi.

Biasanya, kode di handler OID_PNP_SET_POWER Anda berpindah ke EVT_WDF_DEVICE_D0_EXIT dan EVT_WDF_DEVICE_D0_ENTRY.

Karena mesin status daya WDF sedikit berbeda, Anda mungkin perlu membuat modifikasi kecil pada kode.

Secara khusus, dalam fungsi panggilan balik MiniportInitializeEx-nya, driver miniport NDIS melakukan tugas inisialisasi satu kali serta bekerja untuk membawa perangkat ke status D0. Kemudian, ia mengulangi pekerjaan untuk pergi ke D0 di handler OID_PNP_SET_POWER.

Sebaliknya, klien WDF melakukan tugas inisialisasi satu kali dalam panggilan balik peristiwa sebelum EVT_WDF_DEVICE_D0_ENTRY, di mana perangkat berada dalam status daya rendah. Kemudian itu melakukan pekerjaan untuk pergi ke D0 di EVT_WDF_DEVICE_D0_ENTRY.

Untuk meringkas, di WDF, Anda menempatkan kode "buka D0" Anda di satu tempat, bukan dua.

Untuk detail tentang urutan panggilan balik, lihat Urutan Power-Up untuk driver klien NetAdapterCx.

Mengkueri dan mengatur kemampuan manajemen daya

Demikian pula, driver klien WDF tidak menerima OID_PM_PARAMETERS untuk mengkueri atau mengatur kemampuan perangkat keras manajemen daya adaptor jaringan.

Sebagai gantinya, driver meminta konfigurasi wake-on-LAN (WoL) yang diperlukan dari objek NETPOWERSETTINGS. Untuk informasi selengkapnya, lihat Mengonfigurasi manajemen daya.

Bendera aktual yang Anda dapatkan kembali memiliki semantik yang sama seperti yang mereka lakukan untuk miniport NDIS 6, sehingga Anda tidak perlu membuat perubahan mendalam pada logika. Perbedaan utamanya adalah Anda sekarang dapat mengkueri bendera ini selama urutan power-down. Lihat Urutan power-down untuk driver klien NetAdapterCx.

Setelah memindahkan kode ini, Anda dapat menghapus handler OID untuk OID_PNP_SET_POWER dan OID_PM_PARAMETERS.

Karena kerangka kerja NetAdapter menyimpan perangkat Anda di D0 saat host menggunakan antarmuka jaringan, klien biasanya tidak menerapkan logika daya; perilaku daya NetAdapter default sudah cukup.

Jalur data

Model pemrograman jalur data telah berubah secara signifikan. Berikut adalah beberapa perbedaan utama:

Penghapusan perangkat

Penghapusan perangkat untuk driver NIC WDF sama dengan driver perangkat WDF lainnya, tanpa memerlukan pemrosesan khusus jaringan. Jalur data jaringan dimatikan terlebih dahulu, diikuti oleh perangkat WDF. Untuk informasi tentang penonaktifan WDF, lihat Pengguna Melepas Perangkat.

Handler MiniportHaltEx Anda kemungkinan akan didistribusikan antara EVT_WDF_DEVICE_D0_EXIT dan EVT_WDF_DEVICE_RELEASE_HARDWARE.

Klien WDF tidak perlu menghapus NetAdapter atau antrean datapath apa pun yang dibuatnya. WDF menghapus objek ini secara otomatis.

Anda dapat menghapus MiniportShutdownEx, MiniportResetEx , dan MiniportCheckForHangEx. Panggilan balik ini tidak lagi didukung.

Fungsi NDIS-WDF setara

Sebagian besar NdisXxx fungsi dapat diganti dengan WDF yang setara. Secara umum, Anda harus menemukan bahwa Anda membutuhkan fungsionalitas yang sangat sedikit yang diimpor dari NDIS.SYS.

Untuk daftar fungsi yang setara, lihat fungsi NDIS-WDF yang setara.

Awakutu

Lihat Men-debug driver klien NetAdapterCx.

Ekstensi debugger !ndiskd.netadapter menunjukkan hasil yang mirip dengan apa yang ditunjukkan !ndiskd.miniport untuk driver NDIS 6.

Kesimpulan

Dengan menggunakan langkah-langkah dalam topik ini, Anda harus memiliki driver yang berfungsi yang memulai dan menghentikan perangkat Anda.

Catatan: NetAdapterCx saat ini tidak mendukung boot iSCSI.