LINUX.ORG.RU

Намеренное целочисленное переполнение в версиях двух LTS ядер ради тестирования

 ,


2

2

Несколько часов назад Greg Kroah-Hartman выпустил две новые версии LTS ядер серии 4.9.y и 4.4.y в которых y == 256, что должно привести к целочисленному переполнению и к тому, что KERNEL_VERSION(4, 9, 256) == KERNEL_VERSION(4, 10, 0). Никаких других изменений в этих ядрах нет. Сделано это ради тестирования такой нумерации и в частности LINUX_VERSION_CODE в user space (используется такими компоненитами системы, как glibc и gcc) на множестве дистрибутивов. Greg просит пересобрать всю систему вместе с этими версиями ядер и сообщить ему, если что-то перестанет работать или компилироваться. Данное тестирование расчитано, как минимум, на неделю, после которой появятся следующие версии ядер 4.9.y и 4.4.y с настоящими изменениями.

Первоисточник для Ъ:

I'm announcing the release of the 4.9.256 kernel.

This, and the 4.4.256 release are a little bit "different" than normal.

This contains only 1 patch, just the version bump from .255 to .256 which ends
up causing the userspace-visable LINUX_VERSION_CODE to behave a bit differently
than normal due to the "overflow".

With this release, KERNEL_VERSION(4, 9, 256) is the same as KERNEL_VERSION(4, 10, 0).

Nothing in the kernel build itself breaks with this change, but given that this
is a userspace visible change, and some crazy tools (like glibc and gcc) have
logic that checks the kernel version for different reasons, I wanted to do this
release as an "empty" release to ensure that everything still works properly.

So, this is a YOU MUST UPGRADE requirement of a release.  If you rely on the
4.9.y kernel, please throw this release into your test builds and rebuild the
world and let us know if anything breaks, or if all is well.

Go forth and do full system rebuilds!  Yocto and Gentoo are great for this, as
will systems that use buildroot.

I'll try to hold off on doing a "real" 4.9.y release for a 9eek to give
everyone a chance to test this out and get back to me.  The pending patches in
the 4.9.y queue are pretty serious, so I am loath to wait longer than that,
consider yourself warned...

The updated 4.9.y git tree can be found at:
	git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
	https://git.kernel.org/?p=linux/kernel/git/stable/linux-s...

thanks,

greg k-h

>>> Подробности



Проверено: Shaman007 ()
Последнее исправление: Shaman007 (всего исправлений: 4)

Ответ на: комментарий от hummer

не сменил основной компилятор ядра на clang

No,no,no... Хотите как с хромиумом - нового монополиста вместо конкуренции?

snizovtsev ★★★★★
()
Ответ на: комментарий от snizovtsev

Не вижу какой-то особой конкуренции. В GCC многие технические решения принимаются по идеологическим причинам. Вот например, из переписки Каутского с Энгельсом:

https://lwn.net/Articles/629292/

> It is more or less the same loss.  The case I'm concerned about is that
> it become normal to use GCC with proprietary add-ons.

My understanding is that people are satisfied with the current GCC
plugin licensing.  What is at stake here is the development of a stable
output that gives enough info for things like refactoring.

IOW the issue is not disallowing proprietary add-ons (we're all pretty
happy to disallow them, IIUC), but making it impossible to use GCC
within a proprietary product (e.g. a proprietary IDE).

> Nowadays GCC does allow plug-ins -- we came up with a safe way to do
> it (or at least I hope it's safe).  The issue now is to convince
> people to work on improvements to GCC.

Maybe that's the issue for GCC, but for Emacs the issue is to get detailed
info out of GCC, which is a different problem.  My understanding is that
you're opposed to GCC providing this useful info because that info would
need to be complete enough to be usable as input to a proprietary
compiler backend.
hummer
() автор топика
Последнее исправление: hummer (всего исправлений: 1)
Ответ на: комментарий от fsb4000

В разделе «Рабочие загрузки» если поставить галочку «Разработка классических приложений на C++» (не знаю насчет чистого C) с дефолтными галочками и русским языковым пакетом, то пишет суммарно нужно примерно 7 Гб: из них 5 Гб останется в итоге и кэш 2 Гб потом можно удалить. Я не уверен, что все из этого нужно, но там можно установить и удалить любой компонент по отдельности. C++ включает в себя также C, наверное. Просто, я как-то ставил 2010 и 2013 и там C и C++ были отдельно.
У меня Win7. И чтобы установщик корректно запустился сначала нужно установить все обновления (рекомендую с помощью UpdatePack7R2) и .Net Framework 4.8.

anonymous
()
Ответ на: комментарий от hummer

we’re all pretty happy to disallow them

Вот ведь фашики.

anonymous
()

Ты ли это, hummer? Не узнаю тебя. Где призыв переписать линупс на плюсах, инкапсуляции, полиморфизме и вот этом вот всем?

anonymous
()
Ответ на: комментарий от anonymous

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

bhfq ★★★★★
()
Ответ на: комментарий от mord0d

А кто заказчик-то? Кто заказывал LTS ядра? По ходу, их никто и не заказывал. Просто решили, что для удобства компаний должны быть LTS ядра. А зарплата по их поддержке есть только для одного человека. А одного человека для этой задачи мало.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

А зарплата по их поддержке есть только для одного человека. А одного человека для этой задачи мало.

Но оплачивать ещё человеков никто не хочет. Вот пусть сосут лапу, раз экономные.

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

Теперь все всё тестируют на «желающих». Та же мелкософт разогнала отдел тестеров и переложила их работу на инсайдеров…

drfaust ★★★★★
()
Ответ на: комментарий от mord0d

Кто? Если, вдруг, отменят LTS ядра, то, конечно, много кто может взвыть. Но пока что они не заказчики и ни за что не желают платить. Поэтому им и предлагают поучаствовать хотя бы за бесплатно пока есть такая возможность. А то, ведь, и совсем LTS ядра могут отменить, да.

saahriktu ★★★★★
()

4.9 и 4.4 давно использовал, сейчас собирать для теста разве кто будет, а clang чё можно выкинуть? висит пока у меня в emerge -pvc, остался после сборного лиса

spawn_sp ★★★★
()
Последнее исправление: spawn_sp (всего исправлений: 1)
Ответ на: комментарий от mord0d

Что за тупая практика тестировать на юзерах? На зарплату разработчикам хватает, а на зарплату тестерам не?

а в чем проблема-то? ядро есть не попросит, а Грег и разработчикам-то не платит, внезапно.

metawishmaster ★★★★★
()
Ответ на: комментарий от Legioner

Обезьяны не могут писать софт.

Домен:	Эукариоты
Царство:	Животные
Тип:	Хордовые
Класс:	Млекопитающие
Отряд:	Приматы
Семейство:	Гоминиды
Род:	Люди
Вид:	Человек разумный

Будучи гоминидом человек является обезьяной. Упс, блин

anonymous
()
Ответ на: комментарий от anonymous

Не является. Гомини́ды (лат. Hominidae) — семейство приматов, включающее людей и больших человекообразных обезьян.

Legioner ★★★★★
()
Ответ на: комментарий от mord0d

Добро пожаловать в реальный мир

OpenSource не обещает, что вам попадёт хотя бы оттестированная программа, код или ОС. OS лишь гарантирует, что код вы можете получить. Любое использование на ваш страх и риск. С другой стороны за то, что вы не платите деньги за софт вас и используют в качестве тестера. Вы свою плату получили начав пользоваться OpenSource. Такие дела.

small-entropy
()
Ответ на: комментарий от nullb0t

а все началось с того, что кто-то проявил малодушие и отрекся от старого принципа нумерования (версии <= 2.6)
upd: а потом еще и обленился считать натуральные числа %)

metawishmaster ★★★★★
()
Последнее исправление: metawishmaster (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.