Пиша разширение на мрежовото ядро за филтриране на сокет. За да го направи конфигурируем, потребителска програма чете конфигурационен файл и предава информацията на kext през PF_SYSTEM сокет.
Ако искам филтърът за сокет да работи възможно най-скоро при стартиране на системата, как бих хореографирал стартирането?
Сегашната ми идея е да използвам launchd, за да стартирам малка програма за инициализиране на потребителска област. Тази програма ще използва kextload за стартиране на kext. След това той ще прочете конфигурационния файл и ще говори с kext през гнездото PF_SYSTEM. След като свърши работата си, той бързо ще излезе.
Друг вариант би бил да имате два launchd елемента, един за kext (с помощта на kextload) и друг за четеца на конфигурационния файл на потребителската област. Това ще избегне вилицата, но иначе ще бъде идентично. Така или иначе, launchd ще трябва да стартира бърза програма за потребителска област без демон.
Въпреки това, launchd изглежда е насочен към стартиране на действителни демони, а не към бързи задачи, които си вършат работата и излизат. документ на библиотеката за програмисти казва:
Важно: Ако вашият демон се изключи твърде бързо след стартиране, launchd може да помисли, че се е сбил. Демоните, които продължават това поведение, може да бъдат спрени и да не се стартират отново, когато пристигнат бъдещи заявки. За да избегнете това поведение, не изключвайте поне 10 секунди след стартиране.
Това ми създава впечатлението, че launchd не е правилният начин да направите това. Как трябва да организирам стартирането? Дали цялата ми идея върви в грешна посока?
(Като странична бележка, искам да дам на потребителя възможността да променя опциите за филтриране и по време на изпълнение. Предполагам, че това може да стане просто чрез отваряне на нова PF_SYSTEM сокет връзка към kext, когато са необходими промени.)
