LINUX.ORG.RU
решено Форум — Development  

kernel: отслеживание изменения API

 


0

1

Всех приветствую.
Озадачился я тут прикручиванием очередной железяки к системе. Взял значит железку, расчехлил компилятор и начал компелять модуль ядра. Система у меня на базе ядра 3.10.17, а модуль судя по всему заточен под 2.6.х. В целом обработать напильником особой проблемы не вижу.
Проблему вижу в том, чтобы найти информацию вида:
Хацкеры, мы выпилили create_proc_read_entry нафиг в такой-то версии ядра и вместо нее запилили proc_create_data, всем радоваться!
Мы выпилили богомерзкую VM_RESERVED, вместо нее пользуйте вот такой дефайн #define VM_RESERVED (VM_DONTEXPAND | VM_DONTDUMP), всем очень сильно радоваться!
И так далее. Где есть сборище такого рода инфы, чтобы подробно, с каментами и примерами?
Ну и чтобы искать было удобно, а то просматривать логи к каждому релизу крайне утомительно.

★★★★★

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

подробно, с каментами и примерами

Такого ты по определению нигде не найдёшь... По определению опенсорса.

intelfx ★★★★★
()

Где есть сборище такого рода инфы, чтобы подробно, с каментами и примерами?

ну, наверное, git log. подробнее вряд ли найдешь

MyTrooName ★★★★★
()

Ну и чтобы искать было удобно, а то просматривать логи к каждому релизу крайне утомительно.

Внутреннее API ядра нестабильное, поэтому точных планов по его устареванию нет. А раз так, трудно будет предсказать, какие изменения повлияют на твой модуль, а какие нет. Где взять определение, что, мол, «изменения этих функций надо специально документировать, а этих — не надо»? Поэтому придётся, видимо, просматривать логи.

proud_anon ★★★★★
()
Последнее исправление: proud_anon (всего исправлений: 1)

https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt

So, if you have a Linux kernel driver that is not in the main kernel
tree, what are you, a developer, supposed to do? Releasing a binary
driver for every different kernel version for every distribution is a
nightmare, and trying to keep up with an ever changing kernel interface
is also a rough job.

Simple, get your kernel driver into the main kernel tree (remember we
are talking about GPL released drivers here, if your code doesn't fall
under this category, good luck, you are on your own here, you leech
<insert link to leech comment from Andrew and Linus here>.) If your
driver is in the tree, and a kernel interface changes, it will be fixed
up by the person who did the kernel change in the first place. This
ensures that your driver is always buildable, and works over time, with
very little effort on your part.

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

Поэтому придётся, видимо, просматривать логи.

Ладно, я готов на логи. Тем не менее любопытно, кто и как портирует свои дрова на новые версии? Сидят с каждым новым релизом читают, что там отломали, вспоминает есть ли это у него, потом читает исходники и думает как со всем этим взлететь?

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

Нашел кривое решение, время покажет радиус кривизны.
Идем сюда:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/
там есть поле ввода для поиска. Нарыть можно крайне любопытные вещи.
Например: оказывается отказ от create_proc_entry() объявили еще в 2009 году. А выпилили окончательно в апреле 13 года. Но судя по поиску в сети, всем плевать.
Ну и если кто ищет нормальный пример на использование новой версии добро пожаловать в net/core/pktgen.c

yax123 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development