bormant пишет:и получил одинаково успешный результат на всех поддерживаемых версиях ядер.
Выйдет ядро с новым API, разработчик что, заново пишет весь код драйвера? Очень редко что-то заново и ещё многократно реже весь. На стандартные изменения с переименованием полей структур -- стандартные ветвления в коде по KERNEL_VERSION. Если изменения зело существенны -- изменения в Makefile из каких исходников компоновать итоговый модуль в зависимости от версии.
Это всё теория ... в изложении для пыанэров среднего школьного уровня :lol:
И благие намерения ... которыми, как утверждается у Данте: "дорога в Ад вымощена" :lol:
А на практике ... вот вам VPN от бренда - более не бывает - Cisco ... у меня лог сохранился:
[olej@notebook vpnclient]$ sudo ./vpn_install
Cisco Systems VPN Client Version 4.8.02 (0030) Linux Installer
...
make[1]: Entering directory `/usr/src/kernels/2.6.32.9-70.fc12.i686.PAE'
CC [M] /usr/src/vpnclient/linuxcniapi.o
CC [M] /usr/src/vpnclient/frag.o
CC [M] /usr/src/vpnclient/IPSecDrvOS_linux.o
CC [M] /usr/src/vpnclient/interceptor.o
/usr/src/vpnclient/interceptor.c: В функции ‘interceptor_init’:
/usr/src/vpnclient/interceptor.c:132: ошибка: ‘struct net_device’ не содержит элемента с именем ‘hard_start_xmit’
...
И поехали пляски с бубном по интернету в поисках патчей ... а вопросом этим, оказывается, интернет полнится :lol: , тысячи (!) народу решают проблему каждый для своей (под-)версии ядра.
И начинается:
[olej@notebook VPN]$ wget http://lamnk.com/download/vpnclient-linux-2.6.31-final.diff
...
[olej@notebook vpnclient-path]$ patch < ./vpnclient-linux-2.6.31-final.diff
...
Но и этого мало ... потом лезем в исходники и по-маленьку подправляем где ошибки указывает...
И только после этого:
[olej@notebook vpnclient-path]$ sudo /etc/init.d/vpnclient_init start
Starting /opt/cisco-vpnclient/bin/vpnclient: Done
[olej@notebook vpnclient-path]$ lsmod | grep cisco
cisco_ipsec 590314 0
И этот путь прошли все кто возился с Cisco Systems VPN Client...
Так что: теория теорией, пыанэры пыанэрами wink ... а на практике оказывается, что драйвера-модули больше 8-10 подверсий ядра не переживают, и то, что писалось, скажем, для 2.6.19 с ба-а-а-альшущей вероятностью в 2.6.30 компилироваться не станет. Но и компилироваться - это ведб тоже только пол-беды, правда? wink Оно даже если откомпилируется, то достаточно часто модуль в более позднем ядре просто неправильно работает ... тонкие могут вылезать артефакты, но они есть!
bormant пишет:Но концепция от этого не страдает. Внешне и для для 2.4, и для 2.6 единый тарбол и унифицированная процедура.
Я не знаю как там концепция поживает....
Но (если вы заглядывали в kernel API wink ) то в 2.4 & 2.6 там практически ничего общего не осталось!
Вот вам и #ifdef ...
