Анонсирован (http://lkml.org/lkml/2007/7/8/195) выход Linux ядра 2.6.22 (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.22).
Новое ядро поставило своеобразный рекорд - размер
ChangeLog (http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.22) файла достиг 3.8 Мб, а число строк превысило отметку в сто тысяч.Из новшеств (http://kernelnewbies.org/Linux_2_6_22) можно выделить:
- Новый беспроводной стек, ранее открытый компанией Devicescape;
- Новый Firewire стек;
- Системные вызовы signalfd/timerfd/eventfd (http://lwn.net/Articles/225714/) для уведомления через файловые дескрипторы о наступлении события от таймера или поступления сигнала. Дополняет epoll;
- Поддержка архитектуры Analog Devices Blackfin CPU (http://blackfin.uclinux.org/) (Micro Signal Architecture (MSA));
- Драйвер IVTV для MPEG кодировщиков на базе Conexant cx23416/cx23415;
- Два новых алгоритма контроля перегрузки в TCP ('TCP Illinois' и 'YeAH-TCP');
- Переписан планировщик CFQ ввода/вывода;
- SLUB allocator (http://lwn.net/Articles/229984) - система выделения памяти для кеширования объектов ядра, оптимизированная для SMP систем (инструкция slub.txt (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...)).
- Поддержка RxRPC сокетов
- UBI (http://www.linux-mtd.infradead.org/doc/ubi.html) (Unsorted Block Images) - LVM для NAND Flash (маппинг логических eraseblock в физические).
- Реализация POSIX функции utimensat() с поддержкой наносекундных интервалов.
URL: http://lkml.org/lkml/2007/7/8/195
Новость: http://www.opennet.me/opennews/art.shtml?num=11339
Woo-hoo. I'm sure somebody will report a "this doesn't compile, and
I have a new root exploit" five minutes after release, but it still
feels good ;)Линус молодец конечно, его здравый "пофигизм" мне очень нравится :-)
Темп, с окторым прогрессирует Линукс ядро просто радует и пугает одновременно =)
пугает потому что ты не на настолько гибок, чтобы просто принять скорость развития Пингвина.
signalfd/timerfd/eventfd... - скоро изобретем виндовский WaitForSingleObject...
Нет совсем не Single а очень даже мульти ))Только вот в виндовс мульти это <64. Причём в поразительно большом количестве мест встречается это число.
А эти вызовы окучат тысячи событий, таймеров, или сигналов. Удобно, добавлять новые события (новые генераторы событьий), не качаясь работающего обработчика.
Если кто не знает зачем это делается, пусть прочитает про мультиплексирование, чем плохи select и poll ))
В книги Сетевое программирование Стивенсона рассказиваеться о минусах select и poll, во kqueue эти минусы сведены к минимуму
Вот из-за того, что в каждое (!) новое ядро толпы уродцев добавляют чудовищное количество изменений критически важных подсистем, ванильные ядра были, есть и будут непригодными для любой серьезной серверной системы.
Хорошо, что есть Редхат и Сусе.
Уже писалось ведь, что максимально стабильные ядра будут от дистрибутивов, а с кернел.орг самые современные, не глючные, но не самые стабильные. Имхо, так даже лучше. Ничто не будет тормозить прогресс, а стабильности максимальной пусть создатели дистрибутивов добиваются.
Взял 2.6.22.1 наложил POM, интересовало действие TARPIT для iptables. Не собралось, ругается на отсутствие мембера в какой-то структуре. Да новые ядра нужно использовать осторожно :(
Хотя стандартные возможности обычно нормально работают.
> Взял 2.6.22.1 наложил POM, интересовало действие TARPIT для iptables. Не собралось,
> ругается на отсутствие мембера в какой-то структуре. Да новые ядра нужно использовать
> осторожно
не нужно, плз, грать волну.
Не новые, а самопатченные ядра нужно использовать осторожно.
А еще точнее нужно знать, что делаешь.
А если в носу мало - то нече лезть в патчинг ядер.
Ну какое нафиг самопатченное, поддержка netfilter должна быть в первую очередь обеспечена. Или ты хочешь сказать, что без netfilter удобоиспользуемое ядро будет? Брал последний patch-o-matic-ng от 2007-07-10
В новом ядре изменили структуру sk_buff, поэтому многие сторонние модули не компилятся. Но исправить это не сложно.
Ругается на отсутствие мембера "nh". Вопрос что вместо него?
В ipt_TARPIT.c используется где-то в 9-ти местах.
Смотрите Changelog:[SK_BUFF]: unions of just one member don't get anything done, kill them
Renaming skb->h to skb->transport_header, skb->nh to skb->network_header and
skb->mac to skb->mac_header, to match the names of the associated helpers
(skb[_[re]set]_{transport,network,mac}_header).[SK_BUFF]: Introduce skb_network_header_len
For the common sequence "skb->h.raw - skb->nh.raw", similar to skb->mac_len,
that is precalculated tho, don't think we need to bloat skb with one more
member, so just use this new helper, reducing the number of non-skbuff.h
references to the layer headers even more.[SK_BUFF]: Introduce ip_hdr(), remove skb->nh.iph
[SK_BUFF]: Introduce arp_hdr(), remove skb->nh.arph
[SK_BUFF]: Introduce ipv6_hdr(), remove skb->nh.ipv6h
[SK_BUFF]: Introduce skb_reset_transport_header(skb)
[SK_BUFF]: Introduce skb_transport_offset()
[SK_BUFF]: Introduce skb_set_transport_header
[SCTP]: Introduce sctp_hdr()
[ICMP6]: Introduce icmp6_hdr()
[SK_BUFF]: Introduce igmp_hdr() & friends, remove skb->h.igmph
[SK_BUFF]: Introduce udp_hdr(), remove skb->h.uh
[SK_BUFF]: Introduce icmp_hdr(), remove skb->h.icmph
[TCP]: Introduce tcp_hdrlen() and tcp_optlen()
[SK_BUFF]: Introduce tcp_hdr(), remove skb->h.th
[SK_BUFF]: Introduce ipip_hdr(), remove skb->h.ipiph
[SK_BUFF]: Introduce ipipv6_hdr(), remove skb->h.ipv6h
При переходе на новое ядро всегда будет существовать проблема обратной совместимости. От этого никуда не денешься.
Стоит лишь призадуматься о том, что надо четко себе представлять, чего ты хочешь от своей ОС. Стабильность или новизна? Выбор должен сделать каждый.