Apakah mungkin untuk menghubungkan 2 modul kernel ke /dev/device yang sama?

Saya ingin menyimulasikan perangkat mahal dengan mockup perangkat lunak (kami menyebutnya (B)) yang berinteraksi dengan /dev/device sebagai pengganti perangkat sebenarnya

Saat ini modul kernel sudah ada untuk mengelola perangkat sebenarnya yang terhubung ke /dev/device (kami menyebutnya (A)).

Mungkinkah (A) mengirim data ke /dev/device dan (B) membaca data ini, menyiapkan respons dan mengirimkannya kembali ke /dev/device, dan (A) membaca ini tanggapan ?

Jika ada solusi yang lebih mudah untuk melakukan apa yang saya inginkan (yaitu mensimulasikan perangkat keras dengan mockup perangkat lunak) jangan ragu untuk menyarankan.


person Fabien    schedule 14.02.2013    source sumber
comment
Jadi apakah ini (B) mockup atau perangkat nyata? Kalau saya paham betul, maksudnya membuat simulasi di userspace agar bisa berkomunikasi dengan modul Kernel (A) melalui dev/device?   -  person KBart    schedule 14.02.2013
comment
Coba lihat umockdev.   -  person Antoine    schedule 14.02.2013
comment
@KBart (B) adalah mockup perangkat lunak bukan perangkat nyata, tetapi simulasi perangkat yang tidak saya miliki. Dan ya, saya ingin berkomunikasi melalui /dev/device   -  person Fabien    schedule 14.02.2013
comment
@Antoine Saya akan mencari umockdev jika sesuai dengan kebutuhan saya.   -  person Fabien    schedule 14.02.2013
comment
@Antoine Maketnya sudah dikodekan, umockdev sepertinya perlu mengkodekannya lagi dengan Python. Ini mungkin solusi tetapi untuk jangka panjang jika tidak ada jawaban atas pertanyaan ini.   -  person Fabien    schedule 14.02.2013
comment
@Fabien sulit untuk mengatakannya tanpa mengetahui apa yang sebenarnya dilakukan perangkat/driver Anda, tetapi saya akan mengambil pendekatan seperti itu: sambungkan PC kedua dengan menggunakan antarmuka asli (A) atau rutekan ke yang lain (UART, USB, dll.) Di PC kedua melakukan daemonisasi mockup Anda (B) dan terhubung ke dev/antarmuka yang sesuai. Seperti yang saya pahami, Anda ingin memeriksa perangkat itu pada tingkat protokol, jadi antarmuka yang mendasarinya tidak penting. Ini akan terlihat seperti: PC1[dummy_client/logger‹--dev/device‹--›kmodule(A)‹--›interface]‹-----›PC2[interface--›dev/int--›mockup_daemon (B)]   -  person KBart    schedule 15.02.2013
comment
@KBart terima kasih atas solusi Anda. Saya akan mengingatnya. Namun saya lebih suka menggunakan hanya satu PC saja. Hal ini untuk menghindari kerumitan arsitektur pengujian dengan memiliki PC lengkap yang mensimulasikan perangkat kecil. BTW saya sedang menyelidiki peretasan langsung modul kernel (A) untuk memasukkan kode mockup (B) di sana, dan memasukkan kode ke #ifdef #endif untuk pengujian.   -  person Fabien    schedule 15.02.2013
comment
@Fabien dan tujuannya adalah untuk menguji/men-debug kmodule (A) Anda? Jika ya, apa sebenarnya? Jika itu adalah driver perangkat, ia memiliki 2 antarmuka - yang lebih rendah yang menghubungkan perangkat melalui beberapa antarmuka fisik dan yang atas yang menyediakan API (/dev/device) ke ruang pengguna; jadi bagian mana yang menjadi fokusmu? Atau itu hanya tentang logika internal (A) dan antarmuka tidak penting sama sekali?   -  person KBart    schedule 15.02.2013
comment
@KBart tujuannya adalah menggunakan kmmodule (A) yang sama tetapi mengganti perangkat sebenarnya dengan perangkat lunak. Jadi dengan penjelasan Anda, saya kira saya harus memodifikasi bagian bawah kmmodule untuk mengirim informasi simulasi ke atas/dev/perangkat. Saya rasa saya harus mempelajari lebih lanjut bagian ini. Terima kasih.   -  person Fabien    schedule 19.02.2013
comment
@Fabien lihat LDD3 - jika Anda belum pernah melihatnya - ini adalah salah satu titik awal terbaik untuk driver perangkat Kernel.   -  person KBart    schedule 19.02.2013


Jawaban (1)


Anda harus menggunakan driver scull untuk jenis aplikasi ini yang membantu Anda dan juga menyimpan perangkat Anda dan Anda tidak perlu menghubungkan perangkat Anda dan Anda dapat melihat semua aspek dan tes yang Anda butuhkan di driver perangkat sebenarnya.

person ravi bhuva    schedule 19.02.2013