Greg Kroah-Hartman опубликовал отчет (http://kerneltrap.org/Linux/Driver_USB_and_PCI_Subsystem_Upd...) в котором сообщил какие изменения ждут подсистемы USB и PCI в Linux ядре 2.6.24, а также какие общие изменения в инфраструктуру драйверов будут внесены.
Список изменений внушительный, в USB подсистему будет внесено
90 патчей, в PCI - 27, Linux Driver core subsystem - 124 (самое важное - изменение API).URL: http://kerneltrap.org/Linux/Driver_USB_and_PCI_Subsystem_Upd...
Новость: http://www.opennet.me/opennews/art.shtml?num=12238
установил линукс мандрива2007 и теперь мучаюсь с сетевым адаптером аррис на usb система название опредилила а модуль неизвестный
Ставь Ubuntu и не парься =)
Тогда уж лучше windows.
не забудь 150 баксов заплатить за windows
>Тогда уж лучше windows.А чем лучше?Кучами существующих под нее вирусов, спайвари и троянов?
Или встроенной :)))) WGA-спайварью?Или IE7 который по дефолту стучит на сервера микрософт куда вы ходили, прикрываясь борьбой в фишингом?А может активацией, которая может на ровном месте саботировать работу системы?И уж упаси вас боже поменять хард на более емкий - придется отчитываться перед копирастами из микрсофта какой вы нехороший и все такое, потому что активация и в этом случае скажет "отдыхайте, сегодня работать не будем".Патчами раз в месяц?Хакеры если что месяц ждать не изволят, вот редиски то! Поэтому вантузятники традиционно представляют из себя большой ботнет.А может быть, DеRьMом встроенным в систему, столь вам необходимым?Или, может быть, фашистской лицензией?Попробуйте почитать то с чем соглашаетесь.Очень познавательно, узнаете за кого вас держит наглая редмондовская шарага.Рьяных поклонников мазохизма также должен приколоть апдейт который обновляет систему несмотря на то что его отключили.Да и цена системы не разочарует - на выбор или обкусанная дрянь или дорогущая система.При том что линуксные дистрибутивы задаром и не обкусанные.
> изменение APIЗатрахали, да!!!
В 2.6.20+ и так все перекарежило..., только вроде устаканиватся начало, переделали софтины, особено те, которые используют struct sk_buff {} :-Ж
ты не павлинукс, а дятелты читал Documentation/stable_api_nonsense.txt ??
ядро - в разработке. Новая ветка. Чего тебе надо??
Нашли люди какую-то кривизну или чего-то нужного решили добавить.
А по-человечески это оказалось сделать можно лишь изменив API.Или ты хочешь чтоб как в маздае было: криво, но долго и одинаково ???
Совсем рехнулсо?
Ядро всегда в разработке. Ели не в разработке - уже устарело.
В "долго и одинаково" нет ничего плохого. Совсем. В отличие от танцев с API постоянных. Постоянства не хватает.
>В "долго и одинаково" нет ничего плохого. Совсем.об этом никто и не спорил. Ессьно, "долго и одинаково" - говорит о времени и изменениях, но не о качестве.
Я же говорил о постоянно плохом и неизменном качестве: "криво, долго и одинаково". Это несколько отличаеццо от "долго и одинаково".
> В отличие от танцев с API постоянных.ты оттуда же, откуда и павлинух?
Вам нужна разработка или нет?
Если разработка - то это изменения. И изменения НЕ ОБЯЗАТЕЛЬНО обратно совместимые на kernel API уровне. Это ведь другая ветка!
> Постоянства не хватает.Используй ветки 2.6.16 или 2.6.20 - в них только фиксы и нет никаких других изменений.
Постоянства тебе будет на всю жизнь.
Ну а если хочеться каждый раз чего-нить новенького - то КАКОГО ХРЕНА ПЛАКАТЬ, что онои меняют kernel API???
Лично ТЫ способен ПРИДУМАТЬ некое УНИВЕРСАЛЬНОЕ kernel API НАВСЕГДА??? Вот чтоб ЛЮБУЮ фичу можно было прикрутить без ее изменений даже через 50 лет. НЕТ??? Тогда чего ты ждешь от других если даже сам не можешь, умник?
>
>Используй ветки 2.6.16 или 2.6.20 - в них только фиксы и нет
>никаких других изменений.
>Постоянства тебе будет на всю жизнь.
>
>
>Ну а если хочеться каждый раз чего-нить новенького - то КАКОГО ХРЕНА
>ПЛАКАТЬ, что онои меняют kernel API???потому что это требует дохрена работы по переработке старого кода - который вне дерева,
вместо того что бы писать новый. Эта мысль понятна?
Требуется изобретение костылей за место убраной их экспорта функции (ну блин васе захотелось - он не увидел в дереве не одного используещего эту функцию кода).
Мисье вы хоть раз пытались писать код который работает для любой 2.6 ?
Видимо нет - тогда бы задумались о том количестве проверок и костылей которые приходится с собой тянуть.
>Лично ТЫ способен ПРИДУМАТЬ некое УНИВЕРСАЛЬНОЕ kernel API НАВСЕГДА??? Вот чтоб ЛЮБУЮ
>фичу можно было прикрутить без ее изменений даже через 50 лет.
> НЕТ??? Тогда чего ты ждешь от других если даже сам
>не можешь, умник?мисье сбавте тон, хамство показывает вас с худшей стороны.
Было 2.4 vs 2.5 всех все устраивало. Можно было протестировать в -devel ветке новые фичи и потом только вливать в стабильную. Ах -devel никто не ставит и не протестируешь нормально?.. Но пардон мисье - зачем делать из пользователей vanila подопытных кроликов.
Вот даже Мортон сказал что захлебывается в багах vanila. Куда уж рядовым пользователям тогда :)
Ваш идеал это вечно глючащее ядро которое иногда вдруг начинает работать ? тогда вам пожалуй на Windows или на другие OS :)
>потому что это требует дохрена работы по переработке старого кода - который
>вне дерева,
>вместо того что бы писать новый. Эта мысль понятна?"ну вы, блин, даете..." (ц)
к счастью, у девелоперов ядра нет цели поддерживать обратную совместимость с вашим кодом.
Да и странно с вашей стороны хотеть совместимости между разными ветками ядра,
в то самое время когда заявлена возможность любых изменений при таких переходах.Или они не должны ниче менять, тянуть свой древний и кое-где кривой код, не менять его
лишь потому что у вас там что-то не собереться на новой версии? Товарисч, вы идиот.
Взяли два разных ядра и плачетесь, что нет совместимости в их внутреннем API...Это практически то же самое, что взять маздай и BSD - и начать вещать, что вот плохо, что у них kernel API разный.
>Требуется изобретение костылей за место убраной их экспорта функции (ну блин васе
>захотелось - он не увидел в дереве не одного используещего эту
>функцию кода).
>Мисье вы хоть раз пытались писать код который работает для любой 2.6
>?у меня получалсо разный код по мере того, как что-либо менялось связанное с ним.
И неудивительно, ведь API неизменно в 2.6.x ветках, а не во всей 2.6.Я смотрю, вас не беспокоит общий прогресс. Пусть все будет старое, ниче не нужно исправлять даже во внутренней архитектуре - лишь бы вам не нужно было начинать думать...
Топка по вам плачет...
>Видимо нет
смотри выше.
"зьила с*ка?" (ц) Подеревьянский>тогда бы задумались о том количестве проверок и костылей
>которые приходится с собой тянуть.если есть сомнения в моей компетенции - смотрите ChangeLog на 2.6.22.9
и ищите баг, тянущийся с первых .22-rc и аж до .23-rc6
"Fix device address listing for ipv4."урла на багзилле:
http://bugzilla.kernel.org/show_bug.cgi?id=8876и внимательно изучайте имя репортера, приславшего фикс.
>мисье сбавте тон, хамство показывает вас с худшей стороны.
мой тон как раз под стать вашему пониманию Линукса
>Было 2.4 vs 2.5 всех все устраивало. Можно было протестировать в -devel
>ветке новые фичи и потом только вливать в стабильную. Ах -devel
>никто не ставит и не протестируешь нормально?.. Но пардон мисье -
>зачем делать из пользователей vanila подопытных кроликов.Очнитесь, больной... у вас горячка
-devel - это -rcX/-gitX
мало? тестируйте лучше и шлите больше багрепортов на rc ядра.
Ах вы ложили Х на их должное тестирование? Так на кого вы тогда плачитесь?
Как ядро не назови - а с таким отношением в любом "super-mega-stable" будут ошибки.А новые фичи добавлять нужно - ибо это не бздя, которая скоро мхом покроеццо.
Так что, процесс впорядке.
Разве что -rcX фазу я бы раза в два сделал дольше.
Мир не из одних потребителей ядра состоит, много кто и rc тестит. Им стоит дать больше времени.>Вот даже Мортон сказал что захлебывается в багах vanila.
ну вот как с вами по-другому разговаривать?? Вещаете, что тон мой плох.
А вы ЧИТАТЬ умеете?не в багах ваниллы он захлебываеться.
Вот первоисточник, напрягите моск:
http://kerneltrap.org/Linux/2.6.23-rc6-mm1_This_Just_Isnt_Wo...а вот и суть проблемы, высказанной Мортоном:
"Andrew suggested that the -mm process wasn't working as well as it could"Он говорит о разработке -mm ветки (!!!). О том, что присылают много некачественных патчей,
которые без долгих фиксов на ваниллу не накладываються!
Собственно, это как раз святая святых новых фич ядра, как раз та -devel ветка, о которой вы плакались.Так что, возвращаясь к вашим словам, Мортон не в ванильных багах захлебываеться,
а в своих собственных - -mm.
Нафига он принял так много патчей, что ему уже тяжело их обработать??
>Куда уж рядовым пользователям тогда :)тАварисч, рядовые пользователи жмут кнопочку "update" у себя в [К]Убунте и не жужжжат.
Не надо путать
>Ваш идеал это вечно глючащее ядро которое иногда вдруг начинает работать ?
>тогда вам пожалуй на Windows или на другие OS :)дык это именно в венде раз в пятилетку меняют ядерное API.
Это как раз ВАМ туда. Вам стабильности API не хватает.
Про глючащее ядро вы сами придумали, значит, вы об этом думаете и допускаете.
Ну точно вам на венду. Там годами не _ремонтируют_ API, оно стабильное, глючное и заброшенное...
А ты вот себя спроси, что ты лично сделал что-бы это постоянство было?
Сам ты редиска. Короче выдет .24, там глянем, можно было бы обойтись без изменения API иль нет.
>Сам ты редиска. Короче выдет .24, там глянем, можно было бы обойтись
>без изменения API иль нет.а че ждать-то? :)
добавление новых фич в .23 ветку закончилось хрен знает когда.Люди давно уже пачти для .24 пишут и говорят о своих изменениях.
Пройди по ссылке (хоть раз ;) и посмотри список изменений.
Их не так и много.А обойтись без этих изменений конечно же можно было бы.
Но это вот как раз те тягостные размышления, когда сидишь над программулиной
и понимаешь, что вот это вот нужно переписать уже с нуля... иначе будет ппц потом,
даже если сейчас на это забить и кое-как новую фичу прикрутить.
БЛ*!!!!!!!
Да РАДОВАТЬСЯ НУЖНО, ЧТО ДЕВЕЛОПЕРЫ ГОТОВЫ ИДТИ НА ТАКИЕ ВОЛЕВЫЕ ИСПРАВЛЕНИЯ!
Им бы тоже хотелось вместо этого - че-ни тьновенького добавить - но они тратят силы на ФИКСЫ.
Это нужно лишь приветствовать!
Ты чего сегодня, не в настроении?! =)
>Ты чего сегодня, не в настроении?! =)да задрали эти любители стабильности
а вот у нас в OS/2 уже лет 20 апи не меняется (:
>а вот у нас в OS/2 уже лет 20 апи не меняется
>(:вот мудро человек сказал.
В дохлой ОС - ессьно и АПИ не меняецо.
Лишь нечто живое способно изменяться.
И обязано делать это дабы не вымереть...
А соляра тоже дохлая, да? :-)
>А соляра тоже дохлая, да? :-)попробуй просто задуматься над тем, чтоб прикрутить к ней все последние фичи Линуха
и я посмотрю на тебя, пытающегося подстроиться под текущее API соляры.
Дело даже не в том, что оно плохое или хорошее. Оно какое-то.
И это какое-то API _принципиально_ не может подходить под _оптимальную_ реализацию _любой_ фичи.Кто готов с этим спорить - проверьтесь у психиатра перед постом.
Может. Проверялся. =)
> Проверялся. =)ну а результат какой ? ;))
отлично.
тогда, предположим, что API драйверов некого ядра содержит 3 вызова.
Так, для наглядности.Давай на таком API подымем самое простое - линуховый ext2.
вот структура его операций:static const struct super_operations ext2_sops = {
.alloc_inode = ext2_alloc_inode,
.destroy_inode = ext2_destroy_inode,
.read_inode = ext2_read_inode,
.write_inode = ext2_write_inode,
.put_inode = ext2_put_inode,
.delete_inode = ext2_delete_inode,
.put_super = ext2_put_super,
.write_super = ext2_write_super,
.statfs = ext2_statfs,
.remount_fs = ext2_remount,
.clear_inode = ext2_clear_inode,
.show_options = ext2_show_options,
#ifdef CONFIG_QUOTA
.quota_read = ext2_quota_read,
.quota_write = ext2_quota_write,
#endif
};
итого, с квотами это 14 вызовов.ТеперЪ мы имеем делеммму:
- пойти простым путем и постоянно передавать указатель на эту структура-монстра через какой-нить доп. параметр имеющегося API, либо
- все-же изменить API, учтя требования для _человеческой_ реализации подобной сложности файловых систем. Потому как вдальнейшем нам захочеться добавить такую не одну (jfs, reiser, lustre....)Каким путем пойдем, тАварищи??
Пример с API на 3 функции и задачей реализовать 14 можно легко экстраполировать в
рекущие размеры API и то, что может быть придумано в будущем.Кому-то еще непонятно, что изменения API - это нормальный процесс?
>[оверквотинг удален]
>
>ТеперЪ мы имеем делеммму:
>- пойти простым путем и постоянно передавать указатель на эту структура-монстра через
>какой-нить доп. параметр имеющегося API, либо
>- все-же изменить API, учтя требования для _человеческой_ реализации подобной сложности файловых
>систем. Потому как вдальнейшем нам захочеться добавить такую не одну (jfs,
>reiser, lustre....)
>
>Каким путем пойдем, тАварищи??
>Тратим время на создание нормального framework-a для файловых систем. (geom?)
>Кому-то еще непонятно, что изменения API - это нормальный процесс?
Изменения API _внутри_ ядра должны волновать только писатели ядра. Но рядовой пользователь/программист прикладного софта должен иметь свой API.
> Тратим время на создание нормального framework-a для файловых систем. (geom?)Нет, я вообще-то просто как пример взял ФС. Хочешь - замени слово ext3
на "wireless stack" - и пример ничуть не утратит актуальности.>Изменения API _внутри_ ядра должны волновать только писатели ядра. Но рядовой пользователь/программист
>прикладного софта должен иметь свой API.Про прикладное API речь НЕ идет. Оно не ломалось (!! именно не ломалось, а лишь дополнялось новыми системными вызовами) с первых версий Линукса. Так что не о том речь, а именно о врунтиядерном API. И это, действительно, дело лишь девелоперов-ядерщиков.
IMHO, разработчикам ядра необходимо учиться у Дебиановцев. Хоть оно и похоже на ветки: unstable, testing и stable. но все же не хватает ветки experimental, сообщества, выбирамого главу, и большой, скоординированной, команды разработчиков.
Глупости. Ветка experemental - это есть ветка -mm. Сообщество - все линуксоиды, глава - торвальдс, на счет команды не уверен, но сомниваюсь, что она нескоординирована и что она маленькая ;)