>неа. За интерфейс тут отвечает VFS :)
>open(2)
>read(2)
>write(2)
>close(2)
>
>Вот ЭТОТ интерфейс тут использован. Т.е. обычный, файловый. Ага, со здоровенным промежуточным слоем в виде VFS. Нихрена не оптимально.
>>В связи с этим, выглядит как минимум странно фраза "iptables/recent как раз
>>это и есть, самое простое, без спец интерфейса ;) "
>
>VFS - более чем _не_ специальный интерфейс. Без него не бывает линуха
>(говорим о современных версиях). За сим и вещаю, что взаимодействие источника
>списка ИПшников
>(прога cat) и ядра происходит без специального интерфейса (но, безусловно, _с_ интерфейсом!!!),
>а через VFSные вызовы open()/RW()/close()
>
>ipfw же работает с ядром при помощи своего _СПЕЦИАЛЬНОГО_ набора ioctl() запросов.
То же, абсолютно то же делает сам iptables со своими правилами - он, как и ipfw, текстовый вид преобразует к getsockopt()/setsockopt(). Да, кстати, кое-кому не мешало бы подучить матчасть - ioctl() не используется ни в ipfw, ни в iptables.
>[оверквотинг удален]
>
>Доступно?
>
>>ИМХО бардак в голове.
>
>Ну, бардак вытряхивай и читай маны. Они рулят.
>
>а другой - нет, т.е. справедливо сипользовать выражение "без специального интерфейса",
>говоря о работе с ipt_recent.
>А это доступно?
См. выше. Имеем, что в случае iptables появляется уже как минимум ДВА интерфейса - один опциями сокета у iptables, другой через текстовый файл. Который ведет к ДУБЛИРУЮЩЕМУСЯ коду в ядре, мало того, что задействует тормозной VFS, и обрабатывает далеко не все ошибки, которые должен был. Это называется стройная архитектура по Торвальдсу, ы? Это как раз бардак в голове, ведущий к бардаку в ядре.
Если бы автор модуля ipt_recent не выпендривался, а встроился в _уже_ _имеющийся_ интерфейс "специально обученного" iptables (заметим, он уже существует, и никуда от него не деться), то кроме сокращения лишнего кода и общего улучшения качества (использования парсера и проверщика ошибок самих таблесов) стало бы возможным использовать дополнительные фичи - например, единовременный штатный таблесовский COMMIT кучи правил разом, то есть оно стало бы работать куда быстрее на больших объемах.
В результате подход ipfw (и основного iptables) весьма вписывается в unix-way - средство, умеющее делать свою работу, и делать ее хорошо, имеет наружу текстовый интерфейс для других программ, в результате работа по теме сконцетрирована где надо, а не повторяется каждым автором много раз, тем более в ядре, где цена ошибок и скорости куда более высока.
Да, и как уже отмечалось, у ipfw есть препроцессоры, так что, быстро загнать файл с айпишником на строку, не форкая на каждый по процессу, весьма просто:
cat file.txt | awk '{print "table 1 add " $0}' | ipfw -p cat - /dev/null
