هل من الممكن استدعاء وظيفة رد اتصال المستخدم من مساحة Kernel في Linux (IOCTL)؟

Question

هل من الممكن توسيع واجهة IOCTL في Linux بحيث يمكن لتطبيق مساحة المستخدم إرسال مؤشر إلى وظيفة إلى برنامج تشغيل مساحة Kernel؟

أنا أفكر بشكل خاص في طرق للتعامل مع الدفق بطريقة يمكن السيطرة عليها ولكن القيام بذلك في kernel. يمكن إرفاق هذه العمليات بوحدة kernel ، لكن هذا سيجعل التطوير أسهل كثيرًا لأنني لن أحتاج إلى العبث مع النواة أثناء التطوير.

بشكل أكثر تحديدًا ، ستكون هذه هي العملية:

1. يتم قراءة البيانات بواسطة برنامج التشغيل إلى المخزن المؤقت.
2. تتم معالجة البيانات بواسطة هذه الوظائف المعرفة من قبل المستخدم في مكانها.
3. يتم إجراء المزيد من التعاملات ، ربما مع بعض كتل HW.
4. يتم استخدام البيانات بواسطة تطبيق مساحة المستخدم.

Answer 1

أعتقد أنه يمكنك تحقيق ما تريده من خلال جعل برنامج التشغيل الخاص بك يقدم جهازًا أو أكثر من أجهزة الأحرف (أو حظر الأجهزة) التي يتم فتحها لتطبيقات مساحة المستخدم.

ثم يمكنك استخدام عدم التغلب (مقالة Linux Journal) لاتصالات حدث المستخدم في kernel->. IOCTL أو الكتابة إلى الجهاز لمساحة المستخدم-اتصال حدث kernel. يمكن أيضًا تحقيق تبادل البيانات من خلال القراءة/الكتابة إلى ملف أو أكثر من ملفات الجهاز.

بدلاً من ذلك ، يمكنك توفير /proc أو /sys نظام ملفات ملفات أو استخدام NetLink.

قد تفكر أيضًا ksocket:

Ksocket هي وحدة Kernel Linux 2.6 التي توفر واجهات المقبس على غرار BSD (وهي المقبس ، الربط ، الاستماع ، الاتصال ، قبول ، ...) لمطوري kernel لتسهيل شبكتهم progaramming في مساحة Kernel Linux. تعتبر الواجهات Ksocket هي نفسها معادلة في GLIBC ، لذلك لن يكون للمطورين الجدد لمساحة kernel أي عائق في تطوير البرامج المتعلقة بشبكة Kernel.

Answer 2

أعتقد أنك تطلب دائرة مربعة: إذا كان على kernel أن تنفذ وظيفة "userland" الخاصة بك مباشرة ، فلن يكون "userland" ، بل هو نظام الوحدة النمطية القابلة للتحميل. أفترض أن ما أنت حقًا تريد هي وسيلة لمعرفة ما يجب القيام به لجعل كل شيء يعمل دون تحطيم جهاز الكمبيوتر الخاص بك في كل مرة ترتكب فيها خطأ. ربما يمكنك إساءة استخدام معالجات الإشارات كوسيلة لـ "رد الاتصال" ، لكنني صدئ للغاية لأشير إلى كيف ستحصل الى الخلف إلى kernel كما لو كان عن طريق إرجاع استدعاء وظيفة. المشكلة هنا هي أنه في أي مفتاح سياق userland-> kernel ، يبدأ kernel بمكدس جديد ، وبالتالي فإن عنوان الإرجاع قد ولت منذ فترة طويلة. ماذا لو قمت بدمج معالج الإشارة مع mmap'ing /dev /mEM ، ودع المستخدم الخاص بك pseudoDriver يرضي هياكل بيانات برنامج kernel وضع تشغيل kernel مباشرة؟ ولكن بعد ذلك ، تعود إلى إعادة التشغيل عند ارتكاب خطأ ، إلا إذا اكتشفت كيفية mmap فقط هياكل بيانات سائقك؟ قد تكون الآليات الأخرى القابلة لإعادة الشراء هي تدفقات وتخصصات خط tty ؛ أعتقد أن هذه تمنح نوعًا من القدرة على الانتقال. بالطبع لا شيء من هذا هو فكرة جيدة كحل دائم!

Answer 3

حالة الاستخدام الخاصة بك تستمر في ذكر البيانات.

ربما ما تريد القيام به هو مشاركة الذاكرة بين kernel وعملية المستخدم. يمكنك وضع البيانات و/أو الأوامر في الذاكرة المشتركة ، ويمكن لعملية/رمز kernel على الجانب الآخر قراءتها والقيام بأي شيء. يمكن لمكالمة get_user_pages_fast () أن تجعل ذاكرة العملية متاحة للعملية إلى kernel ، حتى عندما لا تكون العملية قيد التشغيل حاليًا.