очередная победа открытых стандартов? :)

А где взять этот самый регистрэйшн? При попытке регистрации она извиняется что не регает никого в данный момент... :(

Новость обрадовала. Если в ближайшие 2 года от микромягких не поступит заявления о портировании оффтопика на Cell, то я усомнюсь в их (микромягких) светлом будущем

эх, открыли бы спецификации для всяких сканеров, фотокамер и винмодемов

linux.alhimia.ru?

> А где взять этот самый регистрэйшн? При попытке регистрации она извиняется что не регает никого в данный момент... :(

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

> Кажется это проблемма из-за мозиллы. :)

Я тоже такое вспоминаю - мозилла не пошла, а NN4 в самый рад.

fi

konqueror регистрация прошла успешно :)

а если выставить в мозиле опознавание браузера как IE?

Кстати, а как это сделать?

> Кстати, а как это сделать?

поставь соответствующий extension для firefox - user agent switcher

неохота регаться - выложите кто-нибудь в открытый доступ плиз.

scei вроде как не просят регистрации http://cell.scei.co.jp/e_download.html

>"SPU C/C++ Language Extensions" Гы-гы-гы. Для каждого процессора - свой C/C++

etogo *nikogda* ne sluchit'sja... HW companies will protect their IP rights. poetomu, Linux will never catch up with Windows or Solaris.

Ой, только без истерики. Уже случилось.

> linux.alhimia.ru?

возможно itc.ua

> etogo *nikogda* ne sluchit'sja... HW companies will protect their IP rights. poetomu, Linux will never catch up with Windows or Solaris.

В 95% случаев неоткрытие спеков - либо инерция мышления, либо желание скрыть "особенности" (т.е. немеренную кривизну) реализации. Ну еще, в случае вайфая, особенности законодательства.

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

А Солярис на x86 линуксу "догонять" в плане поодержки железа не надо, вроде. Скорее, наоборот.

P.S.: интересно, почему бы не продолжить процесс, начатый FUSE, и не сделать DUSE ;) - т.е. Drivers in Userspace. Для низкоскоростных-и-пока-хреново-поддерживаемых устройств на "внешних" шинах (USB/IEEE сканеры-камеры-момеды-звуковухи) самое оно было бы, имхо; да и вайфай можно вполне гонять - он не сильно быстрый, чтобы это сильно сказалось на производительности.

И будет нам микрокернел ;)

> Практически единственная область, где для компаний имеет смысл самим писать драйверы - это видеоускорители, где в дровах живут оптимизации

О, да! :) И по поводу соответсвия картинки 3D Mark в новых дровах nvidia и ati, референсной, некоторое время назад - мы отлично понимаем, что там за "оптимизации" живут, что их надо строго прятать. ;-)

> P.S.: интересно, почему бы не продолжить процесс, начатый FUSE, и не сделать DUSE ;) - т.е. Drivers in Userspace.

Низя. В Linux нет драйверов, есть модули. Но muse уже занято. причём два раза. ;-)

> > P.S.: интересно, почему бы не продолжить процесс, начатый FUSE, и не сделать DUSE ;) - т.е. Drivers in Userspace.

> Низя. В Linux нет драйверов, есть модули. Но muse уже занято. причём два раза. ;-)

Чет ты гонишь, вот. Есть там драйверы, есть. Даже директория такая в дереве исходников есть. А вот в модулях могут быть и не драйверы вовсе - файловые системы, сетевые протоколы, расширения iptables и вообще любая чушь.

Идея драйверов в юзерспейсе в том, что там легче обеспечить API, независимый от структуры ядра; при этом девайсы, для которых это должно быть предназначено тормозные, и их много разных. Что это дает:

- "мирное сосуществование" с закрытыми драйверами (актуально для вайфая). Да, я знаю, что концептуально они маст дай, но во многих случаях деться от них некуда;

- потенциально более стабильное ядро: баг в драйвере кривого китайского Bluetooth dongle не сможет заупсить систему;

- легкость обновления для пользователей: получив "я не знаю такого USB девайса", нужно будет обновлять не ядро (немеренныых размеров, да и страшно - вдруг сломали что-нибудь другое), а некий duse-deviceinfo;

- разделение труда в разработке: ядреным программистам не придется хранить у себя гиганские хидеры с device ids и всякими quircks, а разработчикам драйверов/вендорам железа - пристально читать LKML на предмет изменений в API , и ждать новой версии ядра для появления поддержки.

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

>Идея драйверов в юзерспейсе в том, что там легче обеспечить API,
>независимый от структуры ядра;

Нет принципиальной разницы. Ей неоткуда взяться.
Затея в большинстве случаев откровенно бредовая. По
существу в Linux для любых устройств, используемых
из userspace есть ядерные драйверы. Единственным
распространенным исключением можно назвать только
видео-драйверы X(если без использования AGP и direct rendering),
да и то поиск тех же видеокарт происходит тупо в лоб
через специально предусмотренный ядром интерфейс в /proc.

Такой "userspace" быстро превратится далеко не в userspace
после решения таких вопросов:
1) цивилизованные вызовы в другие модули
2) обращение не к своей ядреной памяти
3) критические(невытесняемые) секции вроде irqsave/irqrestore или обычных spin блокировок
4) память должна быть невыгружаемой, либо такой драйвер должен озаботиться тем, что память может в принципе быть выгружаемой
5) прерывание... как его привести в контекст процесса? через медленное? ну тогда считайте у вас ничего не работает :)

Это только то, что на виду.

>"мирное сосуществование" с закрытыми драйверами (актуально для
>вайфая). Да, я знаю, что концептуально они маст дай, но во многих
>случаях деться от них некуда;

Не будет мирного.

>потенциально более стабильное ядро: баг в драйвере кривого китайского
> Bluetooth dongle не сможет заупсить систему;

Да без проблем... либо он будет неработоспособен.
Кривая DMA передача и свободен. Или программирование не тех портов.
Да даже банальное разыменование 0... просто подумайте, в скольких
различных состояниях системы оно может возникнуть, и как вы его _корректно_ обработаете.

>легкость обновления для пользователей: получив "я не знаю такого USB
>девайса", нужно будет обновлять не ядро (немеренныых размеров, да и
>страшно - вдруг сломали что-нибудь другое), а некий duse-deviceinfo;

А зачем нужно обновлять ядро для какого-то "USB девайса" (по-русски: устройства) вдруг? Соберите модуль нужного устройства, выложите в /lib/modules, сделайте depmod и будет он у вас подхвачиваться вашим hotplug. Примитивный драйвер может воспользоваться инфраструктурой USB подсистемы через /proc(так работает libghoto2).
IMHO, что в винде, что в Linux, сейчас это работает примерно одинаково и вполне цивилизованно.

>разделение труда в разработке: ядреным программистам не придется
>хранить у себя гиганские хидеры с device ids и всякими quircks

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

>разработчикам драйверов/вендорам железа - пристально читать LKML на
>предмет изменений в API , и ждать новой версии ядра для появления
>поддержки.

Резюмирую: идея - полный бред. Как, впрочем, и FUSE(хотя последнее в меньшей степени)

> Низя. В Linux нет драйверов, есть модули.

Ай-яй-яй! А целых 2 звездочки на борту!

#ls /usr/src/linux | grep drivers drivers

Ага... Или _модуль_ nvidia.o.gz делает совсем не то, что _драйвер_ nvagp.sys?

разные идеи )

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

Спрашиватеся не проще ли принять одну терминологию для всего? (модуль для работы с fs, для работы с железом, чем кучу слов?..)

Cell Broadband Engine Architecture ( http://cell.scei.co.jp/pdf/CBE_Architecture_v10.pdf ),
глава 11.1 "SPU Isolation Facility Features"- это ведь не то, о чем я подумал, а?..

> Спрашиватеся не проще ли принять одну терминологию для всего? (модуль для работы с fs, для работы с железом, чем кучу слов?..)

#define модуль_для_работы_с_железом драйвер

Не?

> > Идея драйверов в юзерспейсе в том, что там легче обеспечить API, независимый от структуры ядра; > Нет принципиальной разницы. Ей неоткуда взяться. Затея в большинстве случаев откровенно бредовая. По существу в Linux для любых устройств, используемых из userspace есть ядерные драйверы. Единственным

Именно это мне и не нравится.

> Такой "userspace" быстро превратится далеко не в userspace после решения таких вопросов:

> 1) цивилизованные вызовы в другие модули

> 2) обращение не к своей ядреной памяти

> 3) критические(невытесняемые) секции вроде irqsave/irqrestore или обычных spin блокировок

Ну и нафига все это драйверу, скажем, USB-ADSL-модема? От него требуется зарегать Ethernet или ATM устройство, и кормить его данными, и все.

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

> 5) прерывание... как его привести в контекст процесса? через медленное? ну тогда считайте у вас ничего не работает :) Почему?

Серьезно, /me не ядерный программист - но ведь в хурде это как-то работает (пусть и хреново). В том то и идея, чтобы вынести не все драйверы, а только всякие гаджеты, которые часто обновляются, и "на скорость не влияют"

[snip]

> Примитивный драйвер может воспользоваться инфраструктурой USB подсистемы через /proc(так работает libghoto2).

Ну это почти то, о чем я говорю - только интерфейс должен быть слегка расширен, наверное. Чтобы можно было из user space рулить, скажем, USB WLAN

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

Некоторое время (чуть меньше года) назад, для того, чтобы подключить свой iRiver h340 к линуксу, пришлось править некий файлик в ядре и пересобирать то ли usb_storage.ko, то ли все ядро. Именно по той смешной причине, что для него qiurks не были прописаны.

И файлик был немаленький весьма...

SPU Isolation Facility Features: The Phantom Menace

...а про PS вроде уже известно, что там пользователю будет доступно только 7 SPU на проц (из 8)...

Несколько комментариев (с непрокомментированным согласен).

> Для низкоскоростных-и-пока-хреново-поддерживаемых устройств на "внешних" шинах ([...]IEEE [...]камеры

Вот не соглашусь с тем, что нормальная DV-камера -- низкоскоростное_и_хреновоподдерживаемое устройство. Равно как и видеооцифровщики типа Pinnacle MovieBox DV или Canopus ADVC-55/100/110.

С чем соглашусь -- с тем, что usb должен сдохнуть как класс из-за врождённых ошибок в ДНК.

По скоростям -- для геймеришек с топовым железом 400 Мбит/с (13 Гб/час) -- это как для нормальных людей флоповод, не спорю.

Про миф "поскольку у usb2 аж 480 Мбит/с, то оно быстрее FireWire-400" в курсе, это херня. И даже не из-за того, что сто лет в обед есть FireWire-800

Касаемо поддержки -- прежде чем покупать контроллер и камеру, надо думать головой, а не головкой пейсателя статейки в глянцевом журнальчике. А не вестись на лохозавлекалки типа "hot!!!", "new!!!" "improved!!!" "mainstream!!!" или какие там ещё у рекламодиов бывают словесные диареи.

А какие концептуальные ошибки у технологии USB ?

> А какие концептуальные ошибки у технологии USB ?

Клиент-серверная архитектура. Как следствие, отсутствие шнурков-удлинителей с одинаковыми разъемами, типа "папа". Как следствие, отсутствие сплитеров для USB-клавиатур. Как следствие, невозможно повесить 2 и более маков G5 на 1 клавиатуру, 1 мышь и 1 монитор через 1 сплитер.

Как следствие, на столе как минимум две клавиатуры и две мыши, одна пара из которых занимает лишнее место :)

>Клиент-серверная архитектура.

Вот поэтому USB и получило такое широкое развитие. Благодаря дешевизне, простоте (поддержка USB в MPU мобильников например), малому энергопотреблению (питание от хост-контроллера), миниатюрности (flash-брелоки, bluetooth-донглы и т.д.) клиентской части интерфейса USB появилось столько всевозможных usb-гаджетов.

>Как следствие, отсутствие шнурков-удлинителей с одинаковыми разъемами, типа "папа".

Это потому, что у разработчиков нормальные гетеросексуальные наклонности :)

>Как следствие, невозможно повесить 2 и более маков G5 на 1 клавиатуру, 1 мышь и 1 монитор через 1 сплитер.

А с FireWire возможно?

>Как следствие, на столе как минимум две клавиатуры и две мыши, одна пара из которых занимает лишнее место :)

Конец света! :)

> А с FireWire возможно?

А у тебя есть клавиатура или мышь для FW ? Или ты думаешь, что на G5 есть PS/2 порты ? :)

> Конец света! :)

Ага. А представь теперь 4 машины. Думаешь, удобно работать на ВПП ? Или предлагаешь постоянно лазить под стол ? :)

ПисАл под впечатлением от "usb должен сдохнуть" и "FireWire блаблабла" предыдущего оратора :)

Предыдущий анонимус - это я... Зашел с мобилы и не залогинился :)

> Зашел с мобилы и не залогинился :)

буржуй однако! :)

> концептуальные ошибки у технологии USB

Одну уже назвали.

Вторая -- через неё нельзя прокачать гарантированный поток без затыков и т.п. Просто не предусмотрено. Это я всё про слив/залив DV-потоков талдычу.

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

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

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

>Вторая -- через неё нельзя прокачать гарантированный поток без затыков и т.п.

А как я без затыков на ней смотрю ТВ 720x480 с внешнего ТВ-тюнера? Некомпрессированный...

>Третья -- смехотворно малая мощность, которая предоставляется для питаемых устройств.

А тебе что, киловатт подавать нужно? На 2.5" винт хватает, а на 3.5" нужен такой ток, что у тебя USB-провод будет как у чайника. Нахрен такое удовольствие нужно? Напомнить, как сечение питающего провода расчитывается?

> А как я без затыков на ней смотрю ТВ 720x480 с внешнего ТВ-тюнера? Некомпрессированный...

И какая при этом загрузка процессора?

Простой опыт: берём внешний винтовой бокс, имеющий Firewire и usb2. Прокачиваем туда-обратно пару гиг, смотрим скорости и загрузку проца. На ixbt даже есть статья.

>И какая при этом загрузка процессора?

Если просто смотреть - ничтожная. На 2.8ГГц - несколько процентов.

Вот если на лету писать в DivX - понятно, будет 100%. Но так это компрессия в DivX. В реальном времени :D Кстати, она тоже как бы не оставляет времени на провалы потоку. Тем не менее - целиком кинофильмы себе, вот, записываю - при просмотре записей затыков не вижу.

Так что что-то у тебя с USB2, видимо, не так. Или чипсет не идеальный, или драйвера...

>Простой опыт: берём внешний винтовой бокс, имеющий Firewire и usb2. Прокачиваем туда-обратно пару гиг, смотрим скорости и загрузку проца. На ixbt даже есть статья.

На WinXP/P4P800/P4-2800 перекачка любого объёма данных на переносной 2.5" винт на USB2 систему не грузит. Загрузку процессора не смотрел, но работе не мешает абсолютно. Трансфер - окого 5..6М/б сек, кажется. NTFS.

Сейчас сижу в Gentoo/nForce3/amd64-2200. Записываю 215Мб файл. Пиковая загрузка (изредка) 16%, средняя - 5..10% Субъективно - ни малейших тормозов.

> А как я без затыков на ней смотрю ТВ 720x480 с внешнего ТВ-тюнера? Некомпрессированный...

Рассказываю.

У УСБ есть режим передачи данных -- изохронный называется. Он используется для передачи массивов данных в реальном времени, но он НЕ ГАРАНТИРУЕТ сохранность данных и при сбоях повторно данные не передаются. Используется такой режим в основном для передачи видео и аудио (не сжатых). Я думаю, что ты не заметишь если у тебя на одном из кадров одна из точек поменяет свой цвет. То же самое и с музыкой. Вообще, по спецификации УСБ для изохронного режима передачи данных выделяется до 90% пропускной способности шины (на сколько я помню). Запустить две изохронные передачи того же видео одновременно я думаю проблемотично.

По поводу процов.

Заметил одну тенденцию (или пока ещё не тенденцию) -- с увеличением кол-ва ядер уменьшается тактовая частота. Глядишь, Пень4 3,8Гц останется самым супур-пупер по частоте в истории процестроения. Ещё бы втолковать этим процестроителям что увеличение разрядности не есть гуд, и при увеличении кол-ва ядер в проце можно снижать и разрядность каждого ядра. Четырёхбитные процы не вымерли до сих пор и их усиленно производят.

ЗЫ. Устал писать :-)

> Ещё бы втолковать этим процестроителям что увеличение разрядности не есть гуд, и при увеличении кол-ва ядер в проце можно снижать и разрядность каждого ядра.

Низзя. Адресное пространство приложений от использования многопоточности никак не изменяется, в общем случае. А в 4 гига уже даже на "десктопах" скоро не всё будет помещаться (графика, игры, скрытые от пользователя БД типа умного поиска). Не говоря уж о серверах.

А еще есть задачи, которые плохо распараллеливаются...

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

Тупая экстраполяция говорит, что за 5..10 лет число ядер в писюке доведут до 128..256, а самыми популярными языками станут Erlang и Forth ;-). После чего станет очевидно, что "дальше так жить нельзя", и произойдет "paradigm shift" ;-)

А пока что это все маркетинг...

>Если просто смотреть - ничтожная. На 2.8ГГц - несколько процентов.

При каком траффике?

>Трансфер - окого 5..6М/б сек, кажется.

у меня есть такое устройство (винт с USB2 и FireWare): по USB2 скорость максимум 21 М/с при загрузке процессора 25-30%, по FW - 26 М/с при загрузке <5% (скорость ограничивается скоростью самого винта, по IDE скорость не выше:))

>> Ещё бы втолковать этим процестроителям что увеличение разрядности не есть гуд, и при увеличении кол-ва ядер в проце можно снижать и разрядность каждого ядра.

> Низзя. Адресное пространство приложений от использования многопоточности никак не изменяется, в общем случае. А в 4 гига уже даже на "десктопах" скоро не всё будет помещаться (графика, игры, скрытые от пользователя БД типа умного поиска). Не говоря уж о серверах.

Вообще-то, уменьшить разрядность ядер и продолжать увеличивать разрядность шины адреса, как мне кажется, возможно. Реализуется это по принципу Целл: есть одно Повер-ядро и 8 "маленьких" ядер. С внешним миром общаяется "Мастер-ядро" (формирует расширенные шины адреса/данных) , которое может быть и 128(256) битным. А внутри проца можно и уменьшить разрядность шин.

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

Это скорее вопрос постановки задачи и проектирования решения. Мозг, например, распределённая вычислительная система, выполняющая все операции параллельно. И до сих пор на некоторых задачах быстрее чем всякие Пни4, хотя "тактовая частота" меньше 1 МГц. Пример: формирование визуальных образов.

>Мозг, например "тактовая частота" меньше 1 МГц.

Средняя скорость переключения нейрона за цикл - 7Гц :D (для тех, кто не понял - 7 раз в секунду). Начинает на скоростях в несколько раз больше (20..40, кажется, Гц) но очень-очень быстро "выдыхается". Потом требуется время на восстановление. А задачу решают уже другие нейроны.

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

Читаем еще раз и внимательно, прежде чем задавать глупые вопросы. Особое внимание обратить на то, есть ли у G5 порт PS/2.

Или у Вас полная стойка G5-ых маков ? Тогда ткните пальцем в модель свича, который переключает USB-порты, а заодно USb-шнурки к нему :)

> Средняя скорость переключения нейрона за цикл - 7Гц :D (для тех, кто не понял - 7 раз в секунду).

Так вот почему народу крышу отрывает вместе с гвоздями при воздействии инфразвуком такой же частоты :)

>Так вот почему народу крышу отрывает вместе с гвоздями при воздействии инфразвуком такой же частоты :)

Нет :) Инфразвук опасен на частотах в ~6 Герц. Это резонансная частота внутренних органов.