Щито?

>Чтобы поставить тебе диагноз, не надо быть доктором.

И ты думаешь твой диагноз меня интересует?

Специально для семёнов: драйверы без ядра работать не будут.

Если они будут дублировать функционал друг-друга в рамках одного проекта, это будет уродством.

> Не много ли на себя берёшь?

Чтобы поставить тебе диагноз, не надо быть доктором.

Ну-ну.

Понятно. Алсо, непредсказуемый api - ИМХО попытка удержать разработку драйверов внутри ядра. А т.к. разработка стоит денег, то всё встаёт на свои места.

Т.е. Qt, gtk и куча других библиотек представляют из себя dll-hell и уродство? Не много ли на себя берёшь?

Сравнил жопу с пальцем. В венде стабильный api был почти 10 лет. А тут и 3-х месяцев не бывает. Алсо, вынмобайл совсем другая система. Ты бы ещё 98-ю с линолеумом сюда приплёл.

Удаление модулей вручную? Прям как в венде. Алсо, man mkinitrd, нуб.

Ололол, "стандартный usb-модем" не осилил? Мои соболезнования Твой мозг - труп.

O'RLY? А ну ка расскажи нам, как хорошо дрова от ХП работают в висте и наоборот, а еще раскажи нафейхуа в дирекиксе и WinAPI столь бешеное количество deprecated вызовов, а еще расскажи почему системные вызовы WinCE/Winmobile столь сильно отличаются от десктопных...

поставь Slackware 10, сделай ls -l /dev и ужаснись, пытаясь определить, какой девайс настоящий, а какой нет.

Вот список проблем, которые udev ,была призвана решить:

The Problems: 1) A static /dev is unwieldy and big. It would be nice to only show the /dev entries for the devices we actually have running in the system. 2) We are (well, were) running out of major and minor numbers for devices. 3) Users want a way to name devices in a persistent fashion (i.e. "This disk here, must _always_ be called "boot_disk" no matter where in the scsi tree I put it", or "This USB camera must always be called "camera" no matter if I have other USB scsi devices plugged in or not.") 4) Userspace programs want to know when devices are created or removed, and what /dev entry is associated with them.

И какие из этих проблем реальные, а не выдуманные проблемы? 4 - почему нельзя просто сделать open? 1 - "оно слишком большое", ну и что? 2 - уже решенная проблема 3 - а Linux в Венду он переименовать не хочет?

Поэтому, единственно преимущество udev над devfs была встроенная hotplug функциональность, которая раньше была вынесена в отдельный демон.

Торвальдс уже не торт, а этого Хартмана, судя по его активности, на его место готовят. Поскольку Хартман - сотрудник Новелля, то Новелль таким образом получает контроль над ядром. Элементарно, Ватсон ...

Это железо без дров и без поддержки со стороны производителя/распространителя, так что это как раз к твоему любимому способу «Дрова в отдельном архивчике» относится.

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

Твоя цель тут: http://www.lor-ng.org/forum-talks-1095.html

1. винмодем это не стандарт и тем более к нему нет стандартных дров в винде

2. с таким «стандартом» в винде ты с вероятностью 99% сосёшь

3. если реализацию этого говна таки сделали в линуксе, то 90% что оно будет работать и 10% что железка таки сдохла.

Ты ЛОЛ.

> А вот если вендор не озаботился включить драйверы в ядро или включил, но очень давно, то начинается пляска.

Щито?

> Ой, да не смеши. Драйверы качаются на сайте производителя, да и не припомню, чтобы вот так вот диски выкидывали. Всё таки железки по большей части на гарантии. Алсо, кроме драйверов на nvidia, ati, intel, realek практически больше ничего не нужно, лол.

Давеча вот у знакомого не видно CD-привода на xpSP3. Где дрова брать?

Да, смотри не лопни, мой зелёный друг.

Плодить уродство а-ля dll-hell не маразм?

не могу, ибо дрова на мать 01 г. а до сих пор все номально работает. мб у тебя просто линукс гм?

Ладно и вообще брат, ты меня извини и не обижайся, я тут того погорячился немножечко в треде. :) Просто наверно не понял фишки сразу действительно да и не сразу тебя признал по юзер-агенту узнал бы дак промолчал, все-таки тоже что-то разрабатываешь как говоришь и может быть поэтому мнение на этот счет свое у человека. Ты же прекрасно знаешь, что самый лучший и верный способ разбудить во мне "Владимира Вольфовича" - это начать расхваливать маздай какой он хороший. :)

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

Не знаю я в разработке драйверов не спец, как бы больше по прикладным кросплатформенным аппликухам специализируюсь и никсы меня вполне устраивают для этого, но дрова насколько я знаю пока был вендузятником тоже постоянно обновлялись, постоянно выпускались новые версии драйверов под маздай, там тоже процесс не стоит на месте, что один раз разработали и все. Можешь мне объяснить в чем причина? Почему они дрова постоянно тоже новые версии разрабатывали? Хоть знать буду. :)

Алсо были у меня и на венде траблы с дровами кстати как у эксплуатационщика, был один девайс на базе seleron 333 мегагерца, еще в корпусе форм-фактора AT, ну и получилось так, что когда я на него стал ставить NT (толи 2000-й толи XP) после 9х маздаев, потому что на 9x маздаях у меня уже на нем не работали кое-какие апликухи, то получилось, что дров на встроенную звуковуху не оказалось под NT вообще в природе. И я этот девайс выкинул как морально устаревший, и вот теперь жалею, сейчас бы поставил бы на него какую-нибудь старенькую слаку, и мог бы быть пусть и очень маломощным, но серверком хотябы для экспериментов. Но я то думал, что кроме маздая нет ничего в природе. Вот и выкинул, поодавшись на "клич партии" избавляться от старого железа так как перспективы его туманны. в свете развития программных продуктов. Дурака кусок блин и "потомок однозначный", за то что на поводу у "партии" шел. // это самокритика :)

Ты просто не понял фишки. Это в знак протеста, т.к. со стабильным api в венде всё ок, даже с abi нет проблем. В линуксе же разрабатывать драйвер можно вечно, лол.

А на мобильный модем диск и не нужен. Объяснить почему?

>А был бы линукс, я бы запустил такой модем без проблем и доустановил все что нужно, кодеки всякие и прочее, что в свободных дистрибутивах нет по дефолту по патентным пичинам.

Т.е. всё это можешь сделать по памяти http://ru.gentoo-wiki.com/wiki/MF626? Ололол, нет слов!

Не то слово. Не то что достали, а вобще ... . Мне бы с ними на передачу к Соловьеву "К барьеру". )))

>Алсо, моя цель - обсудить объективные недостатки линукса.

Отлично я не спорю, и понимаю, но зачем хвастать, что я поставил венду вроде достижения какого-то. Вот это просто непонятно честное слово. Ладно бы BSD там или макось накрайняк, но маздай и этим хвастать. Ну не как не пойму этого просто. :)

Я привёл конкретные доводы против нестабильного api. Это уже называется троллингом?

А если это какой-нибудь мобильный USB-модем, и если это деревня за городом и нет него нет дров. ТО что делать возвращяться домой за дровами, а потом снова ехать назад, сколько раз я в такие ситуации попадал тоже. И реально обламывался с баблом из-за этого. А был бы линукс, я бы запустил такой модем без проблем и доустановил все что нужно, кодеки всякие и прочее, что в свободных дистрибутивах нет по дефолту по патентным пичинам.

И что? Они тебя достали? Алсо, моя цель - обсудить объективные недостатки линукса. Но похоже линукс головного мозга по всем симптомам аналогичен вындавсу головного мозга.

>Т.е. те кто критикуют линукс для тебя является защитником мастдая?

Это было не тебе конкретно была адресована порция "виртуального напитка жириновского", а всем пробитым на всю голову маздайшикам, которые даже не знают, что такое линукс и утверждают на своих форумах об "удобстве маздая" для любой домохозяйки. :)

Если речь идёт про win modem, то с линуксом вообще можно отсосать. Алсо, старые модемы в венде поддерживаются. тем более есть такая вещь как стандрат.

Если ты мыслишь категориями вынфака, то кто же виноват.

>cd /lib/modules/`uname -r`/

>rm `find .| grep bullshit.ko`

нуну. Может и программы ты также удаляешь?

Т.е. те кто критикуют линукс для тебя является защитником мастдая? Алсо, непонятно, за каким тогда х*м из мастдая заимствуют говнореестр и прочую хуиту, по причине наличия которой он и является мастадаем? Брали бы лучшее, тогда бы глядишь и вендекапец настал.

А так извините. Даже разрабатывать драйвер и поддерживать под линукс очень дорогое удовольствие, т.к. вместо улучшения приходится терять время на переписывание. Был бы ЖЗ API хотя бы года 2, уже лучше было бы. Алсо, весь софт разрабатывается по этой схеме. Есть стабильная версия - её только исправляют, есть svn версия, где происходят всякие эксперименты. Просто и логично.

аутсешн винфака детектед.

хинт:

cd /lib/modules/`uname -r`/

rm `find .| grep bullshit.ko`

Ну да конечно если рядом у тебя другой комп с интернетами стоит. А представь ситуацию, когда у тебя один комп с обвалившимся маздаем, на котором уже и в интернеты не залезть, чтобы предварительно скачать драйвера и какой-нибудь USB-модем, на который после установки нужны дрова чтобы хоть он заработал, или вообще нет интернетов, то как ты после установки новой системы вообще зайдешь в интернеты, чтобы скачать дрова? Записывать все оборудования, бежать к себе домой качать, что я и делал в таких случаях, а потом снова идти туда же обязательно не все скачаешь этот маздай еще что-нибудь найдет, чего ты не ожидал или не заметил. И сколько лишней беготни?

А что тут понимать? Кто мешает таскать в составе дистра?

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

>Придешь к кому-то диск с маздаем дают, а драйверов нет, или куда-то засунуты, что не найти днем с огнем, а зачастую

Ой, да не смеши. Драйверы качаются на сайте производителя, да и не припомню, чтобы вот так вот диски выкидывали. Всё таки железки по большей части на гарантии. Алсо, кроме драйверов на nvidia, ati, intel, realek практически больше ничего не нужно, лол.

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

PS, и еще после этого, у этих "потомков однозначных" защитников маздая хватает мозгов говорить, что маздай дружелюбная любой домохозяйке система? Я просто фигею над людской тупостью и полным отсутствием мозгов и здавого смысла.

АЛСО:

>The very good side effects of having your driver in the main kernel tree are

Что могу сказать, явный маразм. Запихать ВСЕ драйверы на ВСЕ железки. Что это за максимализм?

ЗЫЖ а кто будет тестировать весь этот зоопарк, а главное когда?

Если следовать твоей логике, то неудаляемый ie в вындавс это очень хорошо.

В каком месте я с этим спорил, лол. Менять надо, но не через каждые же три месяца.

>смотри как раз Stable APi Nonsense

Ага, особенно вот эта фраза "What you want is a stable running driver, and you get that _only if your driver is in the main kernel tree_." Идиот, который это писал явно не в курсе, что есть дрова на железки, которые выпускаются в единичном экземпляре. Нахрена их включать в ядро?

>Хвалишь виндоуз, а "драйвер-паки", интегрированные в большинство пиратских дистров, это разве не то же самое таскание всех драйверов с с обой, а?

>Да, я таскаю с собой практически генерик ведро с кучей всего собранного модулями, но это УДОБНО.

Подойди с позиции разработчика. Переписывать и тестировать драйвер каждые три месяца это УДОБНО?

>4. Хвалишь виндоуз, а "драйвер-паки", интегрированные в большинство пиратских дистров, это разве не то же самое таскание всех драйверов с собой, а?

Кто сказал, что я их хвалю? Алсо, драйверы лежат _ОТДЕЛЬНО_ от ядра и я их могу вообще не ставить. В ос интегрировано только то, что нужно для запуска.

>Домашнее задание: _понять_ stable api nonsense, а так же сделать краткий перевод и изложение на русском языке.

Я даже вычислил того, кто это писал. Судя по его проектам он материально заинтересованная сторона. Что-то аналогичное мы наблюдаем и в вайне.

Greg Kroah-Hartman <greg@kroah.com>

This is being written to try to explain why Linux does not have a binary kernel interface, nor does it have a stable kernel interface. Please realize that this article describes the _in kernel_ interfaces, not the kernel to userspace interfaces. The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still work just fine on the latest 2.6 kernel release. That interface is the one that users and application programmers can count on being stable.

Executive Summary —————– You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.

Intro —–

It's only the odd person who wants to write a kernel driver that needs to worry about the in-kernel interfaces changing. For the majority of the world, they neither see this interface, nor do they care about it at all.

First off, I'm not going to address _any_ legal issues about closed source, hidden source, binary blobs, source wrappers, or any other term that describes kernel drivers that do not have their source code released under the GPL. Please consult a lawyer if you have any legal questions, I'm a programmer and hence, I'm just going to be describing the technical issues here (not to make light of the legal issues, they are real, and you do need to be aware of them at all times.)

So, there are two main topics here, binary kernel interfaces and stable kernel source interfaces. They both depend on each other, but we will discuss the binary stuff first to get it out of the way.

Binary Kernel Interface ———————– Assuming that we had a stable kernel source interface for the kernel, a binary interface would naturally happen too, right? Wrong. Please consider the following facts about the Linux kernel: - Depending on the version of the C compiler you use, different kernel data structures will contain different alignment of structures, and possibly include different functions in different ways (putting functions inline or not.) The individual function organization isn't that important, but the different data structure padding is very important. - Depending on what kernel build options you select, a wide range of different things can be assumed by the kernel: - different structures can contain different fields - Some functions may not be implemented at all, (i.e. some locks compile away to nothing for non-SMP builds.) - Memory within the kernel can be aligned in different ways, depending on the build options. - Linux runs on a wide range of different processor architectures. There is no way that binary drivers from one architecture will run on another architecture properly.

Now a number of these issues can be addressed by simply compiling your module for the exact specific kernel configuration, using the same exact C compiler that the kernel was built with. This is sufficient if you want to provide a module for a specific release version of a specific Linux distribution. But multiply that single build by the number of different Linux distributions and the number of different supported releases of the Linux distribution and you quickly have a nightmare of different build options on different releases. Also realize that each Linux distribution release contains a number of different kernels, all tuned to different hardware types (different processor types and different options), so for even a single release you will need to create multiple versions of your module.

Trust me, you will go insane over time if you try to support this kind of release, I learned this the hard way a long time ago...

Stable Kernel Source Interfaces ——————————-

This is a much more "volatile" topic if you talk to people who try to keep a Linux kernel driver that is not in the main kernel tree up to date over time.

Linux kernel development is continuous and at a rapid pace, never stopping to slow down. As such, the kernel developers find bugs in current interfaces, or figure out a better way to do things. If they do that, they then fix the current interfaces to work better. When they do so, function names may change, structures may grow or shrink, and function parameters may be reworked. If this happens, all of the instances of where this interface is used within the kernel are fixed up at the same time, ensuring that everything continues to work properly.

As a specific examples of this, the in-kernel USB interfaces have undergone at least three different reworks over the lifetime of this subsystem. These reworks were done to address a number of different issues: - A change from a synchronous model of data streams to an asynchronous one. This reduced the complexity of a number of drivers and increased the throughput of all USB drivers such that we are now running almost all USB devices at their maximum speed possible. - A change was made in the way data packets were allocated from the USB core by USB drivers so that all drivers now needed to provide more information to the USB core to fix a number of documented deadlocks.

This is in stark contrast to a number of closed source operating systems which have had to maintain their older USB interfaces over time. This provides the ability for new developers to accidentally use the old interfaces and do things in improper ways, causing the stability of the operating system to suffer.

In both of these instances, all developers agreed that these were important changes that needed to be made, and they were made, with relatively little pain. If Linux had to ensure that it preserve a stable source interface, a new interface would have been created, and the older, broken one would have had to be maintained over time, leading to extra work for the USB developers. Since all Linux USB developers do their work on their own time, asking programmers to do extra work for no gain, for free, is not a possibility.

Security issues are also very important for Linux. When a security issue is found, it is fixed in a very short amount of time. A number of times this has caused internal kernel interfaces to be reworked to prevent the security problem from occurring. When this happens, all drivers that use the interfaces were also fixed at the same time, ensuring that the security problem was fixed and could not come back at some future time accidentally. If the internal interfaces were not allowed to change, fixing this kind of security problem and insuring that it could not happen again would not be possible.

Kernel interfaces are cleaned up over time. If there is no one using a current interface, it is deleted. This ensures that the kernel remains as small as possible, and that all potential interfaces are tested as well as they can be (unused interfaces are pretty much impossible to test for validity.)

What to do ———-

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.

The very good side effects of having your driver in the main kernel tree are: - The quality of the driver will rise as the maintenance costs (to the original developer) will decrease. - Other developers will add features to your driver. - Other people will find and fix bugs in your driver. - Other people will find tuning opportunities in your driver. - Other people will update the driver for you when external interface changes require it. - The driver automatically gets shipped in all Linux distributions without having to ask the distros to add it. As Linux supports a larger number of different devices "out of the box" than any other operating system, and it supports these devices on more different processor architectures than any other operating system, this proven type of development model must be doing something right :)

——

Thanks to Randy Dunlap, Andrew Morton, David Brownell, Hanna Linder, Robert Love, and Nishanth Aravamudan for their review and comments on early drafts of this paper.

И вообще не нравяться драйвера по дефолту сиди на своем "удобном любой домохозяйке" маздае и ставь драйвера вручную, особенно когда диски с драйверами потеряны или их невозможно найти, как это бывает в большинстве случаев на практике.

> Алсо, причём тут вындовс? У кучи библиотек есть стабильный api.

1. Не путай хер с пальцем, а библиотеку с ядром ос. 2. Любой апи рано или поздно, как бы он хоршо не был продуман придется менять. Или как минимум расширять. Это естественный путь эволюции и кто этого не делает - тот вымирает. Из этой концепции любое апи нестабильно. В ядре это приходиться делать чаще обычного - смотри как раз Stable APi Nonsense, там все расписано. 3. Может быть тебе и не хочется таскать кучу драйверов в ядре, а меня устраивает что я воткнул любое железо в усб на ноуте, скажем, и оно в момент завелось без "гугления, качания, далее, далее, готово". Да, я таскаю с собой практически генерик ведро с кучей всего собранного модулями, но это УДОБНО. 4. Хвалишь виндоуз, а "драйвер-паки", интегрированные в большинство пиратских дистров, это разве не то же самое таскание всех драйверов с собой, а?

Домашнее задание: _понять_ stable api nonsense, а так же сделать краткий перевод и изложение на русском языке.

Ну и что запустил дак запустил маздай, как говориться гордись и наслаждайся, "интуитивно понятной операционной системой". И у меня тоже маздай стоит на другой машине, чтобы кое какие кросплатформенные фишки проверять и кое какие навыки отрабатывать и что из этого, я же это не выставляю как предмет гордости, как достижение, а просто на нем нехотя через нехочу проверяю кое-что. Не понимаю вообще зачем, запустить маздай и этим выставляться и гордиться. Идеотизм честное слово. Советую свои комплексы подлечить сначала, прежде чем запусками маздая хвастаться.

А что-то в ядре не нравиться. Акции протеста небось еще в виде пираццкого маздая. Демонстранты х-вы. Люди считай за так нам дают систему, а он еще чем-то недоволен. Вот сколько раз говорилось, что от добра не жди добра. Зажрались совсем.