يُعد بناء Falco من المصدر في Falco المورد الأساسي لفهم كيفية بناء Falco من المصدر. بالإضافة إلى ذلك، يقدم مستودع falcosecurity/libs معلومات قيمة إضافية حول اختبارات وتصحيح الأخطاء في المكتبات الأساسية وبرامج تشغيل النواة الخاصة بـ Falco.

فيما يلي مثال لأمر cmake سيتيح لك كل ما تحتاجه لجميع اختبارات الوحدة في هذا المستودع:

cmake \
-DUSE_BUNDLED_DEPS=ON \
-DBUILD_DRIVER=ON \
-DBUILD_FALCO_MODERN_BPF=ON \
-DCREATE_TEST_TARGETS=ON \
-DBUILD_FALCO_UNIT_TESTS=ON ..;

قم ببناء مجموعة اختبارات الوحدة وتشغيلها:

nproc=$(grep processor /proc/cpuinfo | tail -n 1 | awk '{print $3}');
make -j$(($nproc-1)) falco_unit_tests;
# Run the tests
sudo ./unit_tests/falco_unit_tests;

اختياريًا، يمكنك بناء برنامج التشغيل الذي تختاره وتجربة تشغيل ثنائي Falco لإجراء اختبارات يدوية.

أخيرًا، نقل مشروع Falco اختبارات الانحدار الخاصة به إلى falcosecurity/testing.

1. كُتبت الأسطر الأولى من التعليمات البرمجية في أساس Falco منذ فترة، حيث لم تكن Go قد اكتسبت بعد نفس المستوى من النضج والاعتماد كما هو الحال اليوم.
2. نموذج تنفيذ Falco تسلسلي وأحادي الخيط بسبب متطلبات الحفاظ على الحالة (statefulness) للأداة، وبالتالي فإن معظم مزايا وقت تشغيل Go المتعلقة بالتزامن لن يتم استغلالها على الإطلاق.
3. يتعامل كود Falco مع برمجة منخفضة المستوى للغاية في العديد من الأماكن، ونعلم جميعًا أن الربط بين Go وC ممكن لكنه يجلب الكثير من التعقيد والمفاضلات.
4. بصفته أداة أمان مصممة لاستهلاك إنتاجية عالية جدًا من الأحداث في الثانية، يحتاج Falco إلى استخلاص أقصى أداء من جميع المسارات الساخنة في وقت التشغيل ويتطلب تحكمًا عميقًا في تخصيص الذاكرة، وهو ما لا يمكن لوقت تشغيل Go توفيره (هناك أيضًا جمع القمامة (garbage collection) المتضمن).
5. على الرغم من أن Go لم تناسب المتطلبات الهندسية لنواة Falco، إلا أننا ما زلنا نعتقد أنها يمكن أن تكون مرشحًا جيدًا لكتابة امتدادات Falco عبر نظام الإضافات. هذا هو السبب الرئيسي وراء منحنا اهتمامًا خاصًا وأولوية عالية لتطوير plugin-sdk-go.
6. Go ليست شرطًا للحصول على ثنائيات مرتبطة ثابتًا (statically-linked). في الواقع، نوفر إصدارات Falco ثابتة بالكامل منذ بضع سنوات. المشكلة الوحيدة فيها هي أن نظام الإضافات لا يمكن دعمه مع نموذج المكتبات الديناميكية الحالي لدينا.
7. صُمم نظام الإضافات لدعم لغات متعددة، لذا فإن الحفاظ على قاعدة تعليمات برمجية متوافقة مع C من جهتنا هو أفضل استراتيجية لضمان أقصى توافق عبر اللغات.
8. بشكل عام، لدى الإضافات متطلبات/اعتماديات GLIBC لأنها تحتوي على روابط C منخفضة المستوى مطلوبة للتحميل الديناميكي. يمكن أن يكون الحل المحتمل للمستقبل هو دعم ربط الإضافات بشكل ثابت في وقت الترجمة ومن ثم إصدارها مدمجة داخل ثنائي Falco. على الرغم من عدم بدء أي عمل في هذا الاتجاه بعد، إلا أن هذا سيحل معظم المشكلات التي أبلغت عنها وسيوفر أيضًا ثنائيًا ثابتًا تمامًا. بالطبع، لن يكون هذا متوافقًا مع التحميل الديناميكي بعد الآن، لكنه قد يكون حلاً قابلاً للتطبيق لإصدار Falco المُبني بشكل ثابت.
9. سلامة الذاكرة هي بالتأكيد مصدر قلق، ونبذل قصارى جهدنا للحفاظ على مستوى عالٍ من الجودة حتى وإن كانت C++ عرضة للأخطاء إلى حد كبير. على سبيل المثال، نحاول استخدام المؤشرات الذكية (smart pointers) كلما أمكن، ونبني المكتبات باستخدام address sanitizer في بيئة التكامل المستمر (CI)، ونشغّل Falco عبر Valgrind قبل كل إصدار، ولدينا طرق لاختبار الإجهاد (stress-test) لاكتشاف الانحدارات في الأداء أو استخدام الذاكرة غير الطبيعي (على سبيل المثال: https://github.com/falcosecurity/event-generator). علاوة على ذلك، لدينا جهات خارجية تدقق قاعدة التعليمات البرمجية من وقت لآخر. لا شيء من هذا يحقق موقف سلامة مثاليًا بالطبع، لكننا نحاول تعظيم فرصنا. من هذا المنظور، ستجعل Go حياتنا أسهل بالتأكيد، لكن المفاضلات لم تجعل الأمر يستحق العناء حتى الآن بسبب النقاط المذكورة أعلاه.
10. قاعدة التعليمات البرمجية C++ لمكتبات falcosecurity/libs، التي تشكل جوهر Falco، كبيرة ومعقدة للغاية. سيكون نقل كل هذا الكود إلى لغة أخرى جهدًا كبيرًا يتطلب الكثير من موارد التطوير مع احتمالية عالية للفشل والانحدار. لذلك، كان نهجنا حتى الآن هو اختيار إعادة الهيكلة (refactors) وصقل الكود بدلاً من ذلك، حتى نصل إلى مستوى أمثل من الاستقرار والجودة والنمطية في ذلك الجزء من الكود. من شأن ذلك أن يجعل التطويرات المستقبلية أكثر سلاسة وقابلية للتحقيق.