Через год в Linux ядре будет блокирована работа закрытых модулей

Не в ядре, а в пространстве ядра по велению пользователя. kernel.org закрытого не распространяет.

>А возможно 2 состояния - стремление к господству или вялое болото. Линус не хочет болота для того, на что потратил столько времени.

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

Пропала романтика just for fun, а именно это, imho, позволило сделать Linux.

>Shaman007 ***** (*) (14.12.2006 19:56:05)

> Если эта т.н. "свобода" становится самоцелью и ограничивает МОЮ свободу - нафиг не надо ее.

А вы, простите, кто? Анператор вселенной? Лорд Зину? =) Кто это вам сказал, что свобода - это ваша свобода делать всё, что угодно. Это как раз - анархия. Ваша свобода кончается у границ моего носа.

Love it or leave it. Или, как говаривал один мой друг: Не нравится - иди нах отсюдова.

Делай свою операционку со своей лицензией.

>Отлично, ограничения ввели, теперь у нас нет 3д и некоторых других полезных штук которые раньше были. Для меня лично ничего в лучшую сторону не поменялось. Что я сделаю? Уйду в другую систему. И так поступят многие. Да, у тебя останится идеологически чистый Linux с которым непонятно что делать и который используют два с половиной смешных человека. Из production системы он превратится в свободную игрушку для академических целей. Если ты с ним играешь - все нормально, я с ним работаю и работать мне в таком раскладе станет невозможно.

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

Получится как Google - пока он толко разворачивался, всем было наплевать на рынок - 'google makes market', а теперь CIO/CEO очень волнуются, когда акции падают из-за чего-то неудачно сказанного.

>Shaman007 ***** (*) (14.12.2006 19:41:58)

>>В Linux это - ерунда, и да происходить будет относительно редко.

>Что? syscall? надеюсь вы понимаете, что это read/write и т.п. Раньше внутри драйвера в kernelspace все происходило, а теперь на каждый чих нужно будет делать syscall - пишешь в регистр, копируешь данные, включаешь dma... - будет очень тормозной интерфейс.

:D Ничего такого не будет. Я постил уже эту ссылку на статью о юзерспейсных драйверах: http://www.linuxsymposium.org/proceedings/reprints/Reprint-Chubb-OLS2004.pdf. почитай(те).

>>я не совсем понял, что такое recovery, но page faults буду не чаще, чем в ядерных драйверах.

>В ядре их практически не бывает - т.к. нет переключения контекста

Причем здесь переключения контекста? Перед выполнением операции В/В драйвер должен fault in все страницы, в этом участвующие (get_user_pages или copy_from_user) - это самые обычные page fault'ы. То же самое (и не больше) придется сделать и юзерспейсному драйверу.

Когда Вы покупаете ботинок - Вы знаете, что Вы покупаете. При покупке закрытого софта Вы можете только верить в то, что он делает то (и только то!), что делает. Вы же наверняка знаете это так же хорошо, как я? (хорошая идея - подарить Вам соньковский плейер с условием поставить на комп ТУ САМУЮ софтинку?;)

На сегодня - мешанина закрытого и закрытого - именно в ядре. В едином адресном пространстве живут закрытый и открытый код. Как раз запрет на закрытые драйвера _В_ЯДРЕ_ привел бы к тому, о чем Вы говорите "он есть в драйвере, который на совести вендора". И тогда действительно ядро - никаким боком.

Как раз на данный момент Радеон покупать лучше, чем нвидиа - для него опенсорцные дрова лучшего качества. Лучше Радеона в этом смысле только интел. Просто при покупке надо среди прочего смотреть на поддержку открытыми дровами - и возможность НЕ использовать дрова вендора. Потому как рано или поздно (скорее рано, по закону подлости) вендор "забьет" на старые железяки и тогда придется сосать лапу.

Тут сложнее. Если народ ради удобства начинает использовать двойные стандарты, то где граница? Почему можно разрешить nVidia поставлять закрытые модули, но нельзя разрешить D-Link поставлять решения на базе Linux в закрытом варианте? А им так удобнее!

> Еще раз - никто не запрещает закрытые драйвера. Их предлагали запретить ТОЛЬКО В ЯДРЕ (да, тотальный их запрет, хотя идеологически был бы мечтой, на этом глобусе не прокатит).

svu, скажите пожалуйста, в будущем вы планируете работать как профессиональный системный разработчик с основным профилем по *NIX/Linux системам? вопрос достаточно личный so на ответе я отнюдь не настаиваю. но если все-таки планируете, то про слово "GPL" я бы порекомендовал забыть до очень далёких и других времён.. :)

ps: не котируется оно, слово GPL. совсем. AFAIS конечно. разве что под профи подразумевать постера патчей в LKML или коммитера в дерево *BSD и никак иначе :)))

// wbr

Можете объяснить разницу между "ядром" и "пространством ядра", если мы говорим не об исходниках, а работающем в памяти моего компа ядре?

>Что же вы не плачете, что вас ограничивают в свободе воровать чужой код по лицензии GPL? Если уж считаете себя такми белыми, то идите до конца, а в противном случае получается потребительство в худшем смысле этого слова - сейчас это выгодно, т.к. игрушка запустится, поэтому я за бинарные драйвера, а завтра, когда бинарный драйвер (аппаратную прошивку, чип в мозгу и т.п.) через DRM запретит игарть музыку, начнете выть, что вас снова ограничивают.

А вот лично мне нужна свобода, пусть пользователь сам решает, что ему использовать, а никак не разработчики, дистров/ядра. А иначе мы дойдём до обсурда, знаете как в СССР где секса не было...

>Линус просто боится, что от Линукса отвернутся, а ему хочется мирового господства, поэтому он предлагает сначала дистрибутивам сделать первый шаг, а затем и он подтянется.

А вот это очень странная и не понятная позиция, ни к чему хорошему она его не привидёт, как не приводят ни к чему хорошему все полумеры.

>rtc (*) (14.12.2006 19:51:33)

> Тормоза при пересечении границы kernelspace/userspace в syscalls (несмотря на то, что они самые быстрые по сравнению со всем коммерческими unix и windows), page faults & recovery при копировании больших объемов данных.

>кстати, это не совсем так: QNX даже 4.й лохматой версии* позволял на одном и том же железе (~PIII 1GHz +/-) переключать контекст между процессами примерно в 10..15 раз быстрее, чем это делает *BSD aka сделать ~250000 честных переключений в секунду для него совсем не проблема. честно скажу - не тестировал, но почти уверен, что это утверждение справедливо и для Linux/Solaris бо во всех трёх системах syscall - это *очень* дорогая операция.

В qnx syscall - это совсем не syscall в unix, там (x86) разве те же int 80, а не программное переключения контекста?

Btw, Linux 2.6 pre-vdso, athlon64 3500+ 2.2 Ghz - 100 наносекунд время пустого syscall.

>klalafuda * (*) (14.12.2006 20:02:24)

>>Что же вы не плачете, что вас ограничивают в свободе воровать чужой код по лицензии GPL? Если уж считаете себя такми белыми, то идите до конца, а в противном случае получается потребительство в худшем смысле этого слова - сейчас это выгодно, т.к. игрушка запустится, поэтому я за бинарные драйвера, а завтра, когда бинарный драйвер (аппаратную прошивку, чип в мозгу и т.п.) через DRM запретит игарть музыку, начнете выть, что вас снова ограничивают.

>А вот лично мне нужна свобода, пусть пользователь сам решает, что ему использовать, а никак не разработчики, дистров/ядра. А иначе мы дойдём до обсурда, знаете как в СССР где секса не было...

Ну так пользуйтесь freebsd, а в Linux есть правила. Не нравятся эти правила - не пользуйтесь, но вернетесь, т.к. во freebsd практически нерабочий smp, vmm и т.п.

>>Линус просто боится, что от Линукса отвернутся, а ему хочется мирового господства, поэтому он предлагает сначала дистрибутивам сделать первый шаг, а затем и он подтянется.

>А вот это очень странная и не понятная позиция, ни к чему хорошему она его не привидёт, как не приводят ни к чему хорошему все полумеры.

Он просто ничего не делает - ни да, ни нет, выжидает...

>Ygor * (*) (14.12.2006 20:13:07)

> QNX даже 4.й лохматой версии*

Ну так у него микроядро жило в Process Manager, так что он "практически" монолит. А вот как у QNX 6 с этим дела ;)

> ~250000 честных переключений в секунду

1e9/2.5e5 == 4000, т.е. 4 МИЛЛИСЕКУНДЫ? Здесь какая-то ошибка. У OS/2 на Pentium100 было 40 МИКРОсекунд.

> В qnx syscall - это совсем не syscall в unix, там (x86) разве те же int 80, а не программное переключения контекста?

syscall в QNX 4.x на x86 [единственная платформа] - это то-же вызов программного прерывания. 0xF7 AFAIR впрочем с конкретным номером могу соврать. но идея та-же самая и ничего нового в качестве гейта они не придумали. вся прелесть в том, что делается дальше.. :)

> Btw, Linux 2.6 pre-vdso, athlon64 3500+ 2.2 Ghz - 100 наносекунд время пустого syscall.

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

// wbr

Да какой из меня системый разработчик? Жабабыдлокодер и тролль ЛОРовский;)

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

> P.S. "Автор, жжжжжошЪ! Пиши еще!" (С) :) P.P.S. Мон шер ами, а о чем мы вообще тут спорим? :)

Круче. Фура :) только что обосновал, что для сохранения гарантии необходимо использовать с железкой только софт её производителя. Интересно, а на процессорах Intel можно пускать только ПО от Intel? Или они особенные, на них гарантия не отваливается? lol

>>Что? syscall? надеюсь вы понимаете, что это read/write и т.п. Раньше внутри драйвера в kernelspace все происходило, а теперь на каждый чих нужно будет делать syscall - пишешь в регистр, копируешь данные, включаешь dma... - будет очень тормозной интерфейс.

>:D Ничего такого не будет. Я постил уже эту ссылку на статью о юзерспейсных драйверах: http://www.linuxsymposium.org/proceedings/reprints/Reprint-Chubb-OLS2004.pdf. почитай(те).

Это про ide? Я не помню ссылку, но читал про ide, когда они готовили презентацию для OLS. Там показан сферический конь в вакууме.

>>я не совсем понял, что такое recovery, но page faults буду не чаще, чем в ядерных драйверах.

>>В ядре их практически не бывает - т.к. нет переключения контекста

>Причем здесь переключения контекста? Перед выполнением операции В/В драйвер должен fault in все страницы, в этом участвующие (get_user_pages или copy_from_user) - это самые обычные page fault'ы. То же самое (и не больше) придется сделать и юзерспейсному драйверу.

Как раз в copy_*_user() они и случаются - именно из-за этого (и начальных накладных расходов на проверки) он заметно тормознее memcpy(). А ядру не надо копировать данные - оно запустило dma для двух регионов, и эти регионы останутся в памяти, пока не произошло переключение контекста, которое в ядре не произойдет. Это конечно утрировано и не совсем правда (просто некоторые страницы лочатся), но суть отражает - копирование данных в userspace из kernelspace и наоборот _очень_ медленная операция. А локирование памяти очень неэффективная операция.

>tailgunner (*) (14.12.2006 20:09:48)

> QNX даже 4.й лохматой версии*
> Ну так у него микроядро жило в Process Manager, так что он "практически" монолит. А вот как у QNX 6 с этим дела ;)

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

> 1e9/2.5e5 == 4000, т.е. 4 МИЛЛИСЕКУНДЫ? Здесь какая-то ошибка. У OS/2 на Pentium100 было 40 МИКРОсекунд.

без кода и тестов это заявление голословно и не принимается. потрудитесь написать тесты. это очень просто.

// wbr

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

простите, вы все-таки определитесь - вы хотите посвятить своё время "ломанию стереотипов" или же разработке ПО? это две совершенно разные вещи и два разных пути.

// wbr

>простите, вы все-таки определитесь - вы хотите посвятить своё время "ломанию стереотипов" или же разработке ПО? это две совершенно разные вещи и два разных пути.

Почему нельзя совмещать? Кто запретил :)

>Ну так пользуйтесь freebsd, а в Linux есть правила. Не нравятся эти правила - не пользуйтесь, но вернетесь, т.к. во freebsd практически нерабочий smp, vmm и т.п.

Вы знаете, я таки и использую FreeBSD на своём маленьком десктопе(да я знаю сейчас сотня красноглазых, заорёт BSD - R.I.P.). Из закрытых дров я пользуюсь драйверами nvidia.

Вот вы кажется разработчик(по крайней мере у меня складывается такое впечатление, когда я читаю ваши посты)--- объясните мне почему мне запрещено пользоваться чем то, хотя те же дрова нвидии никак не противочат GPL?

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

> Почему нельзя совмещать? Кто запретил :)

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

// wbr

>Но что меня больше поражает, так это то что я никогда не слышал высказываний разработчиков FreeBSD по таким вот политическим вопросам, они просто делают своё дело и всё.

Но Линукс все-таки флагман :)

> Это про ide?

и про Gigabit Ethernet тоже

> Там показан сферический конь в вакууме.

Можно подробнее - чем это отличается от RealWorld (tm) драйверов?

> в copy_*_user() они и случаются - именно из-за этого (и начальных накладных расходов на проверки) он заметно тормознее memcpy().

ЕМНИП, с ядра 2.2 перед copy_*_user() не делается никаких проверок - функция запускается, но по ходу может нарваться на fault (и будет -EFAULT).

> оно запустило dma для двух регионов, и эти регионы останутся в памяти, пока не произошло переключение контекста, которое в ядре не произойдет.

О йоптыть, вся Библия нафиг :D Переключение контекста ни при чем - они остануться в памяти до page_cache_release), а переключение произойдет - во время ожидания завершения В/В ядро запустит какой-нибудь процесс.

> копирование данных в userspace из kernelspace и наоборот _очень_ медленная операция.

Это обычное копирование памяти (если страница не paged out, конечно).

А БСД в фарватере

забыл дописать :)

#include <sys/time.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdlib.h>
#include <time.h>
#include <stdio.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
	struct timeval tm1, tm2;
	int num, i, fd;
	long diff;
	double speed;

	if (argc != 2)
		return -1;

	num = atoi(argv[1]);

	fd = open("/dev/zero", O_RDONLY);
	if (fd == -1)
		return -1;

	gettimeofday(&tm1, NULL);
	for (i=0; i<num; ++i)
		read(fd, &i, 0);
	gettimeofday(&tm2, NULL);

	diff = (tm2.tv_sec - tm1.tv_sec)*1000000 + (tm2.tv_usec - tm1.tv_usec);
	speed = (double)diff/(double)num;

	printf("num: %d, diff: %ld, speed: %f.\n", num, diff, speed);
	close(fd);
	return 0;
}

$ gcc -W -Wall -O0 ./syscall_test.c -o syscall_test
$ ./syscall_test 100000
num: 100000, diff: 30264, speed: 0.302640.
$ ./syscall_test 1000000
num: 1000000, diff: 290732, speed: 0.290732.
$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 6
model name      : Intel(R) Pentium(R) D CPU 3.40GHz
stepping        : 5
cpu MHz         : 3740.092
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 3
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm
bogomips        : 7485.86

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 6
model name      : Intel(R) Pentium(R) D CPU 3.40GHz
stepping        : 5
cpu MHz         : 3740.092
cache size      : 2048 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 3
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm
bogomips        : 7480.62


0.2 микросекунд.

> 0.2 микросекунд.

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

// wbr

За деньги - разрабатываю ПО. В свободное время - ломаю стереотипы ;)

> цыкл шоль поставьте для приличия.. покрутиться пару минут и взять среднее.. :)

хотя вру, слона я не заметил, пардон. давайте проверим..

// wbr

>> 1e9/2.5e5 == 4000, т.е. 4 МИЛЛИСЕКУНДЫ? Здесь какая-то ошибка. У OS/2 на Pentium100 было 40 МИКРОсекунд.

>без кода и тестов это заявление голословно и не принимается.

Я и не собирался ничего доказывать. Любому очевидно, что приведенные вами цифры - ОТНЮДЬ не рекорд.

Кстати: для QNX4 лет 10-12 назад производителем декларировалось время переключения контекста ~40мкс, и interrupt latency ~20мкс. Это всё - на 486DX/33. У остальных операционок РВ эти цифры были раза в 1.5-2 ниже.

>>тормоза юзерспейс по сравнению с кернелспейс -миф?

>Тормоза при пересечении границы kernelspace/userspace в syscalls (несмотря на то, что они самые быстрые по сравнению со всем коммерческими unix и windows), page faults & recovery при копировании больших объемов данных.

>>wieker * (*) (14.12.2006 18:33:56)

Даже по техническим вопросам сколько людей столько и мнений ;)

>> Это про ide?

>и про Gigabit Ethernet тоже

> Там показан сферический конь в вакууме.

>Можно подробнее - чем это отличается от RealWorld (tm) драйверов?

> в copy_*_user() они и случаются - именно из-за этого (и начальных накладных расходов на проверки) он заметно тормознее memcpy().

>ЕМНИП, с ядра 2.2 перед copy_*_user() не делается никаких проверок - функция запускается, но по ходу может нарваться на fault (и будет -EFAULT).

Ну посмотрите же в исходники, теоретик...

>> оно запустило dma для двух регионов, и эти регионы останутся в памяти, пока не произошло переключение контекста, которое в ядре не произойдет.

>О йоптыть, вся Библия нафиг :D Переключение контекста ни при чем - они остануться в памяти до page_cache_release), а переключение произойдет - во время ожидания завершения В/В ядро запустит какой-нибудь процесс.

page_cache_release здесь не при чем - оно может вообще никогда не произойти :) Скорее уж lock/unlock_page.

>> копирование данных в userspace из kernelspace и наоборот _очень_ медленная операция.

>Это обычное копирование памяти (если страница не paged out, конечно).

Теоретик... Вот вам ссылка на картинку, нашел на днях (как раз по такому же вопросу беседа была) изучайте.

http://www.mail-archive.com/netdev@vger.kernel.org/msg09370/memcpy_vs_copy_user. png

>tailgunner (*) (14.12.2006 20:31:45)

> Нет, назвать продукты не могу -- такой вот хреновый агримент, что в течении 5 лет после прекращения контракта я не должен ничего говорить.

Как нехорошо, променял свободу на какой-то агримент.

> Их предлагали запретить ТОЛЬКО В ЯДРЕ (да, тотальный их запрет, хотя идеологически был бы мечтой, на этом глобусе не прокатит).

Запрет В ЯДРЕ несколько лет назад тоже был мечтой, а теперь, как видим... Дай волю фанатикам, они любые (закрытые) запретят. И что тогда?

Разъяснение для картинки - делается соответствующая операция в цикле, количество операций указано на горизонтальной оси, скорость - на вертикальной. Операция копирования блоками по 1, 4 и 32 страницы, copy_user делается для всего блока сразу (т.е. без накладных в цикле!). и он явно сливает.

По крайней мере это то, как я понял объяснение автора в рассылке.

> Я и не собирался ничего доказывать.

понял, отстал (c) FIDO

> Любому очевидно, что приведенные вами цифры - ОТНЮДЬ не рекорд.

конечно, конечно..

> Кстати: для QNX4 лет 10-12 назад производителем декларировалось время переключения контекста ~40мкс, и interrupt latency ~20мкс. Это всё - на 486DX/33. У остальных операционок РВ эти цифры были раза в 1.5-2 ниже.

вторичное п.1

ps: и зачем тогда ввязываться в дискуссию? чисто на понтах? не котируется. а клеймо btw ой как трудно смывается.. :-/

// wbr

>> Там показан сферический конь в вакууме.

> Можно подробнее - чем это отличается от RealWorld (tm) драйверов?

Так чем же? Ответь, как практик :)

>>О йоптыть, вся Библия нафиг :D Переключение контекста ни при чем - они остануться в памяти до page_cache_release), а переключение произойдет - во время ожидания завершения В/В ядро запустит какой-нибудь процесс.

>page_cache_release здесь не при чем - оно может вообще никогда не произойти :)

ну, ошибки бывают, особенно у вас, практиков ;) Насчет "page_cache_release ни при чем" - значит, LDD3 нам лгет? :'(

> Скорее уж lock/unlock_page.

не припомню такой функции. Может, SetPageLocked?

Да, а переключение контекста - оно может произойти? ;)

Про copy_from_user - пошел утюжить тексты.

> Можете объяснить разницу между "ядром" и "пространством ядра", если мы говорим не об исходниках, а работающем в памяти моего компа ядре?

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

> Как нехорошо, променял свободу на какой-то агримент.

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

>>> Там показан сферический конь в вакууме.

>> Можно подробнее - чем это отличается от RealWorld (tm) драйверов?

Так чем же? Ответь, как практик :)

Надо вспоминать - давайте завтра в этом же теме, сейчас пора уходить.

>>>О йоптыть, вся Библия нафиг :D Переключение контекста ни при чем - они остануться в памяти до page_cache_release), а переключение произойдет - во время ожидания завершения В/В ядро запустит какой-нибудь процесс.

>>page_cache_release здесь не при чем - оно может вообще никогда не произойти :)

>ну, ошибки бывают, особенно у вас, практиков ;) Насчет "page_cache_release ни при чем" - значит, LDD3 нам лгет? :'(

Не знаю, на что конкретно вы ссылаетесь, но page_cache_release() это всего лишь освобождение памяти, как free(), оно не имеет никакого отношения к page fault и т.п.

>> Скорее уж lock/unlock_page.

>не припомню такой функции. Может, SetPageLocked?

Это всего лишь выставляет бит - функция, которая спит на бите и непосредственно выставляет - lock_page()->__lock_page():
static inline void lock_page(struct page *page)
{
	might_sleep();
	if (TestSetPageLocked(page))
		__lock_page(page);
}


>Да, а переключение контекста - оно может произойти? ;)

Когда? При preemptible kernel сожет почти везде (где явно не запрещено).

>Про copy_from_user - пошел утюжить тексты.

>tailgunner (*) (14.12.2006 20:50:39)

>Он известный беспринципиный бизнесмен. Давно узнал?

Ты "Just for fun" читал? Если и читал, то явно ни хрена не понял.... =\

> понял, отстал (c) FIDO

Неправильно понял - я просто уточнял цифры

>> Любому очевидно, что приведенные вами цифры - ОТНЮДЬ не рекорд.

>конечно, конечно..

Неужели ты _всерьез_ думаешь, что 4 МИЛЛИсекунды на переключение контекста - это рекорд? 8-O

> вторичное п.1

Не знаю, сочтешь ли ты эти данные достойными своего высокого доверия, но http://www.openqnx.com/PNphpBB2-viewtopic-t6159-.html там линк на PDF. В этом PDF времена порядка МИКРОсекунд.

> а клеймо btw ой как трудно смывается.. :-/

Да на мне этих клейм ;) А когда приду устраиваться на работу - я ж не представлюсь tailgunner'ом :-P

А мы вообще зачем рождены-то? Чтоб сказку (="мечту") сделать былью!;)

Ну всё, писец Linux-у! А всё так неплохо начиналось.

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

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

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

> Пока-что мы вполне живые львы. А вот хурд на льва не тянет. Ни на мертвого (он никогда им не был) ни тем более на живого.

Может он ещё не родился? :-)

А знаешь чем кончится дело? OpenSolaris'ом. Вот тебе и будет true GPL unix с дровами и без заморочек.

А при чём здесь Solaris?

>Толстый дядя потому и толстый, что напишет на железке то, что ему выгодно, а не то, на что она реально (или даже гарантированно!) способна.

Писец, сам себе противоречишь.... Кем, пля, "гарантированно"?? Тобой? Оверклокерами малолетними? Гарантировать может _только_сам_дядя_. И как это он и пишет на железке. Остальное --- ни разу не гарантии, а домыслы и фантазии.

".... - Хр-р-р! - сказала новая бензопила и задымилась. - То-то же! - сказали сибирские мужики и довольные пошли валить лес вручную."

> Надо вспоминать - давайте завтра в этом же теме, сейчас пора уходить.

Договорились

> Не знаю, на что конкретно вы ссылаетесь

На книгу "Writing Linux Device Driver, 3rd edition", ее все называют LDD3

> но page_cache_release() это всего лишь освобождение памяти, как free(), оно не имеет никакого отношения к page fault и т.п.

page_cache_release - это совсем не free. Она unpin страницу кэша страниц, делая эту страницу доступной для page out. Сама она, конечно, page fault не вызывает.

>>Да, а переключение контекста - оно может произойти? ;)

>Когда?

Я говорю о вашей фразе: "эти регионы останутся в памяти, пока не произошло переключение контекста". Насколько я знаю (и LDD* со мной согласна), переключение контекстов не имеет никакого отношения к тому, остануться ли регионы в памяти - они остануться в ней, пока драйвер явным образом не разрешит им уйти (а может, и дольше - если нет memory pressure).

>Мы не пустим вас в концлагерь, даже если там солнце ярче, трава зеленее, вода мокрее и сахар слаще.

А кто, йопрст, решил что он ВПРАВЕ РЕШАТЬ ЗА МЕНЯ? о_О

Хренасе "свобода"....