[Ivan_83]

вот я поражаюсь ЧСВ некоторых freebsd'шников. если очень хочется, сделайте mv /sbin/ip /sbin/ncf или любое другое приемлемое для вас имя.

Я с линухами тоже работаю и под них тоже пишу.

Internet Protocol = IP

у меня вызывает диссонанс такое название команды для управления всем что не IP, те всякими адаптерами.

Второе это абсолютно не человечьи аргументы самой комманды: набирать их удобно но нихера не понятно что они значат и трудно запомнить эту абракадабру.

 

iproute2 нормально живёт что на 2.6.32, что на 3.9-rc2, а у вас 8.x => 9.x ломает sockstat/netstat и проч. для

В линухах апи/аби тоже постоянно ломается :)

 

В линухе:

- accept не наследует флаг NON_BLOCK от родительского сокета (поэтому они сделали ещё один, правильный accept4() - где его можно руками выставить %) );

- sysctl - унылое гамно: нет много чего и даже hw раздела, а парсить "файлы" из /proc/ не слишком удобно ради пары параметров;

- epoll - просто жалок в сравнении с kqueue и приходится это компенсировать кучей доп сисколов;

- sendfile - кастрат в сравнении с аналогами в др ОС (даже винда круче!) и приходится это компенсировать доп сисколами;

- в линухе нет: SO_REUSEPORT, SO_NOSIGPIPE, SO_SNDLOWAT опций сокетов;

- линух в принципе на знает сколько свободного места для отправки у него в сокете %)

- в линухе нет accept фильтров;

Короче, я от этих ваших линухов тоже настрадался :)

[bos9]

простой пример:

 

root@wks0:~# ip a s dev dsw0

6: dsw0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

link/ether fe:54:00:04:16:b5 brd ff:ff:ff:ff:ff:ff

inet 192.168.99.1/24 brd 192.168.99.255 scope global dsw0

valid_lft forever preferred_lft forever

inet6 fe80::58df:fff:fe39:e27e/64 scope link

valid_lft forever preferred_lft forever

 

root@wks0:~# ifconfig dsw0

dsw0 Link encap:Ethernet HWaddr fe:54:00:04:16:b5

inet addr:192.168.99.1 Bcast:192.168.99.255 Mask:255.255.255.0

inet6 addr: fe80::58df:fff:fe39:e27e/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:172122 errors:0 dropped:0 overruns:0 frame:0

TX packets:214865 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:107526909 (107.5 MB) TX bytes:241897647 (241.8 MB)

 

 

root@wks0:~# ip a a 192.168.88.1/24 dev dsw0

root@wks0:~# ip a s dev dsw0

6: dsw0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP

link/ether fe:54:00:04:16:b5 brd ff:ff:ff:ff:ff:ff

inet 192.168.99.1/24 brd 192.168.99.255 scope global dsw0

valid_lft forever preferred_lft forever

inet 192.168.88.1/24 scope global dsw0

valid_lft forever preferred_lft forever

inet6 fe80::58df:fff:fe39:e27e/64 scope link

valid_lft forever preferred_lft forever

 

root@wks0:~# ifconfig dsw0

dsw0 Link encap:Ethernet HWaddr fe:54:00:04:16:b5

inet addr:192.168.99.1 Bcast:192.168.99.255 Mask:255.255.255.0

inet6 addr: fe80::58df:fff:fe39:e27e/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:172122 errors:0 dropped:0 overruns:0 frame:0

TX packets:214879 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:107526909 (107.5 MB) TX bytes:241899324 (241.8 MB)

 

Убедили! Встречал такое при конфигурации десктопов через network-manager, но не придал значения. Будем приучать себя к новому синтаксису, хоть он и в самом деле очень не запоминающийся.

[^rage^]

Второе это абсолютно не человечьи аргументы самой комманды: набирать их удобно но нихера не понятно что они значат и трудно запомнить эту абракадабру.

вообще-то всё достаточно осмысленно и в стиле cisco.

 

В линухах апи/аби тоже постоянно ломается :)

для сторонних драйверов - да. но системные утилиты - это нонсенс.

 

В линухе:

- accept не наследует флаг NON_BLOCK от родительского сокета (поэтому они сделали ещё один, правильный accept4() - где его можно руками выставить %) );

accept() в posix 1.2008

т.е. никто такого поведения не гарантирует. не удивлюсь, если на solaris/aix аналогично.

 

- sysctl - унылое гамно: нет много чего и даже hw раздела, а парсить "файлы" из /proc/ не слишком удобно ради пары параметров;

файлы - универсальный интерфейс. что делать для доступа из perl/ruby/python/java? спавнить процесс sysctl?

и чего именно из hw интересовало?

 

- epoll - просто жалок в сравнении с kqueue и приходится это компенсировать кучей доп сисколов;

конкретика? тем более, есть inotyfy/fanotify аналогов которым нет(как timerfd).

 

- sendfile - кастрат в сравнении с аналогами в др ОС (даже винда круче!) и приходится это компенсировать доп сисколами;

если вам чего-то не хватает - есть splice/tee/vmsplice.

вот у меня задача - копировать данные из одного fd в другой не заходя в юзерспейс. по факту, это 2 раза позвать splice( fd0 => pipe => fd1).

причём, fd - любые. хоть сокеты, хоть файлы. а sendfile только из файла в сокет может.

 

 

- линух в принципе на знает сколько свободного места для отправки у него в сокете %)

эээ... а точнее?

 

- в линухе нет accept фильтров;

 

а зачем? есть TCP_DEFER_ACCEPT. всё равно только приложение знает что делать с запросом, да и ядерная память не резиновая.

[Ivan_83]

accept() в posix 1.2008 т.е. никто такого поведения не гарантирует. не удивлюсь, если на solaris/aix аналогично.

Это логичное - наследовать флаг.

акепт4 - порнуха, как и флаги туда передаваемые.

 

файлы - универсальный интерфейс. что делать для доступа из perl/ruby/python/java? спавнить процесс sysctl? и чего именно из hw интересовало?

HW_MACHINE, HW_MACHINE_ARCH, HW_MODEL, hw.clockrate, HW_NCPU, HW_PHYSMEM.

Парсить /proc/cpuinfo не очень то приятно и там далеко не всё что нужно мне.

 

конкретика? тем более, есть inotyfy/fanotify аналогов которым нет(как timerfd).

Можно пачкой добавлять, читать, удалять.

Можно работать не только с файлами.

Возвращает размер сколько можно прочитать/записать, номер ошибки и пр.

Таймеры тоже есть, как и файловые нотификации и тп. http://www.freebsd.org/cgi/man.cgi?query=kqueue&apropos=0&sektion=0&manpath=FreeBSD+8.2-RELEASE&arch=default&format=html

 

если вам чего-то не хватает - есть splice/tee/vmsplice.

Нет возможности указать буфера для отправки до и после отправки файла.

 

эээ... а точнее?

Как узнать сколько можно записать в сокет в линухе? - НИКАК!

 

а зачем? есть TCP_DEFER_ACCEPT. всё равно только приложение знает что делать с запросом, да и ядерная память не резиновая.

Для днс/хттп и некоторых других много места не нужно, в худшем случае всегда можно слить приложению.