`

СПЕЦІАЛЬНІ
ПАРТНЕРИ
ПРОЕКТУ

Чи використовує ваша компанія ChatGPT в роботі?

BEST CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Андрей Зубинский

Об одной проблеме Android, и даже не столько Android

+1414
голосов

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

Поясню на типовом примере, с которым неизбежно столкнутся все пользователи подобных устройств. У вас есть нечто - например, таблет, в котором реализован USB-хост. И вот вы этому нечто бодро и радостно в USB-порт втыкаете какую-то полезную штуку. Например, 3G/4G/WiMax модем. И что просиходит? С вероятностью 90% (а то и все 100%) - системное сообщение "устройство не поддерживается". А какой год на улице? 2010-й? Это нормально в 2010-м году такое вот, да? По-моему, это ненормально.

А всё почему? А всё потому, что на системном уровне, похоже, пещерный век. А именно, - драйверы "торчат" там, где, по идее, у таких устройств им быть не место. На том же системном уровне. А где они должны быть? Конечно, в userspace. Потому что в этом случае можно определить тип подключенного устройства и что сделать? Правильно - подкачать драйвер из какого-то ...store (если он там, конечно, есть), запустить процесс с ним и тем самым дать возможность пользователю стать полноценным пользователем того, что у него имеется.

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

Вот с этим очевидным соображением насчёт драйверов в user space - оно же под ногами валяется, и первое, о чём думаешь, глядя на результат "втыкания" обычного ходового во всём мире 3G-модема в новенький красивенький таблет - так именно о несоответствии между мордашками, тактильным интерфейсом и прочими милыми рюшечками и элементарной невозможностью использовать то, что, очевидно, должно быть можно использовать. По крайней мере, для использования чего не видно препятствий.

То же самое можно сказать и о файловых системах всей этой "мелочи". Я имею в виду сетевые файловые системы. В ОС Plan 9 и Inferno с незапамятных времён это отработано. Больше того, файловые серверы Plan 9  и протоколы портированы чуть ли не на всё, на что можно портировать. Ну почему бы не дать возможность пользователю таблета автоматически подключаться (wifi есть везде) к домашнему серверу (или к публичному) и совершенно прозрачно смотреть-читать-слушать файлы прямо с сервера? Да, для этого надо делать серверную и клиентскую часть. И кусок клиентской части надо "заталкивать" в системный уровень. Что для стороннего производителя ПО, не участвующего в проектировании конкретного устройства в существующей модели просто невозможно. Нельзя ему туда. То есть, можно, но это уже хак, который на месте не всякий пользователь сделает. А если бы, если бы поддерживались userspace-драйверы, было бы всё иначе.

К слову, нюанс с драйверами в userspace - большой, очень большой плюс к... хорошо забытой и недооцененной ОС типа Minix. Да, Minix это может, она так устроена. Принципиально так устроена. У неё все драйверы в userspace. И вот если всё что поверх ядра Linux в Android перенести и поместить над ядром Minix, может получиться куда более совершенная система. В первую очередь - с точки зрения пользователя. В принципе, и в Linux есть возможность создавать и использовать драйверы в userspace (даже API как будто устоялся) - так используйте её, дорогие производители, используйте.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365

+1414
голосов

Напечатать Отправить другу

Читайте также

Позволю себе не согласиться. Выносить драйвера в юзерспайсе плохая идея. Это уже не операционная система будет, а ms-dos какой-то, где каждая прикладная программа могла лазить в железки как ей заблагорассудиться и делать там все что угодно. И про аппрат виртуальной памяти тогда тоже надо забыть. Да много чего... Весь современные ОС, даже маленькие, будь-то закрытый iOS или открытый Android, все равно построены на принципах изоляции пользователя (читай чайника или злодея) от потенциально (преднамерено) опасных действий. Современный пользователь (особенно таких девайсов как тут рассматриваются) в основной своей массе не имеет специальных компьютерно-программистских знаний. Поэтому, идя "в народ", в массовый консьюмерский сектор, надо обезопасить себя от проблем "сушки кошки в микроволновке". А на уровне карманного девайса, с точки зрения среднестатистического пользователся, поломка в софте ничем не отличается от просто "кирпича". Термин "кирпич", в отношении такой электроники, очень хорошо знаком любому, кто хоть раз интересовался возможностью что-то сделать "без разрешения вендора".
Это я все к чему, гораздо проще, на мой взгляд, заинтересованным сторонам, "встраивать" (я умышленно написал в кавычках, дабы не придирались к слову) драйвера для поддерживаемых ими ОС в сам девайс. Как это реализовать - другой вопрос, простейшей реализацией является решение HUAWEI в отношении своих модемов - встроенная флэшка, опознаваемая как CD с autorun в корне. Далее все делает операционка. Понятное дело, для iOS & Andriod такое сейчас не пройдет, но, это как раз и есть тот вопрос, которым надо озаботиться разработчикам этих ОС. Ведь совершенно реальная и выполнимая задача предоставить открытый интерфейс к уровню ядра для драйверов физических устройств. За примерами ходить далеко не надо, взять loadable modules в Linux или Sun's DDI/DKI. Эдакий AppleStore по отношению к драйверам ;)

Такое делают производители некоторых USB-модемов, и это есть правильно.

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

почитайте документацию по Minix и какую-нибудь классическую книгу по архитектуре Unix (Баха рекомендую), чтобы мы не тратили время на игры на разных полях.

здесь всё правильно сказано.

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

но.

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

Я не буду с вами спорить о том, кто лучше знает архитектуру *NIX систем, и общие принципы проектирования ОС, а очень хотелось :), я все равно так красиво не выскажусь, специальность не та.

Вернемся к предмету.

Послушался. Полез почитал доку по MINX, сначала показалось, что я не про то подумал. Я игрался с ней, когда она только появилась. Дипломная работа нескольких студентов, призванная показать, что такое возможно. Показали, молодцы. Хорошая идея для учебных целей, на очень ограниченом наборе железа. Поэтому она и получилась длиной меньше 4000 срок. У нас тоже когда-то была написана своя операционка взамен тогдашней, для ЕС1020, DRT называлась. ;) Но то что MINIX развивают, не забросили - молодцы, этого не отнять. Хотя реального коммерческого применения ей найти трудно.
Почему? Весь функционал работы с конкретным железом перенесен в ядро. То, что они называют "драйвер", на самом деле просто пользовательская прога реализующая некую интерфейсную или бизнес-логику в рамках строго ограниченной и жестко захаркоженой идеологии работы с определенным железом, предоставляемых ядром.
Исходя из вашей логики, им, бедным, надо затолкать все многообразие интерфейсов и протоколов существующей перефирии в ядро. Я просто молчу про нечто более специальное, чем модем или SATA контроллер. Вот, например, такое http://www.fastcomtec.com/products/product-lines/ultra-fast-multiscalers... И чем, в итоге, это будет отличаться от описываемого ими "монолитного ядра"? А, зачастую, внутреняя структура и принцип работы девайса вообще являются проперти вендора. И что в этом случае будет делать это универсальное ядро?
Пример из жизни. Я не могу отказаться от видны и перейти на National Instrument RTOS, т.к. драйвера есть только для видны. NI RTOS заточена только под определенные принципы работы железа, от NI. А вышеописанная карта - проперти интерфейс и конкуренты NI, и они никогда не отдадут им потроха своего железа.

И еще раз вернусь к тому, что я написал. В реальной жизни, даже в Линухе, уже давно используется тот же принцип. "Монолитного" ядра, в отношении драйверов нет уже добрых 10 лет. Все драйвера - loadable. Для изменения драйвера уже давно не надо ничего перегружать и перекомпиливать ядро. Про более похожие на операционные системы UNIX Solaris, IBM AIX, HPUX, даже говорить не приходиться.

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

MINIX - вовсе не дипломная работа "нескольких студентов", побойтесь Бога такое утверждать. Если бы вы были в теме, то знали бы непременно, что на MINIX, архитектуру, реализацию и идеологию которой создавал Эндрю Танненбаум (к слову, голландец с Украинскими корнями, http://en.wikipedia.org/wiki/Andrew_S._Tanenbaum ), выучились практически все, кто сегодня делает фактически *nix мир, знали бы о затяжном споре между Танненбаумом и Торвальдсом и не стали бы говорить о дипломной работе, в 1987 году Танненбауму было 33 года, какая дипломная работа, вы о чём, вместе с системой писалась и культовая книга, учебник для студентов.

О Боже! Ну что вы несёте? Что? Длиной менее 4000 строк вас смутило? Это реализация микроядра сокращена до 4 тысяч строк с шести. Потому что микроядро-с. В QNX оно тоже крошечное. В макаке (пардон, MacOS X) - вот там микроядро очень большое. Потому что очень старое и разработано как раз именно студентами в рамках дипломных работ во времена, когда идеология микроядра только продумывалась фактически - http://en.wikipedia.org/wiki/Mach_kernel.

Что вас смущает в API драйверов? Многообразие? Так давным-давно во всех по-людски сделанных системах API драйверов сформирован и его, вы не поверите, намертво устаканили, вы попробуйте ради интереса в Windows нашаманить драйвер с нестандартным API. Более того, чем лучше и чётче ограничен API драйверов, тем лучших и больше самих драйверов для системы есть. Windows - самый наглядный пример. Впрочем, и для Linux модуль ядра с нестандартным API вы не напишете никак. Разве что ядро перепишете.

Если в пользовательской системе есть возможность во время эксплуатации уменьшить количество модификаций системной области - надо уменьшать. Почему? Microsoft'овцы вам расскажут - у них опыта с пользовательской ОС побольше чем у кого угодно в мире, да и вы сами додумаетесь, если подумаете. А если есть возможность при создании новой системы на архитектурном уровне решить такую задачу - надо решать. Тем более, что с падением цены на NAND флэш всё больше производителей будут использовать inplace-исполнение системного прямо из флэш. Надо объяснять почему? Потому что в таком случае система становится более устойчивой ко всякой гадости. Больше того. Такое уже есть. Давеча гики шумели по поводу какой-то модели смартфона HTC, по-моему, в которой системная область на аппаратном уровне восстанавливается в оригинал после программных модификаций хаками.

Так что всё правильно, не сомневайтесь. Подгружаемые модули ядра - это для больших машин, не для встраиваемого ПО (по-хорошему, и для больших машин это не лучшее решение, просто оно уже есть). В нём, по классике embedded - системное сидит в "зеркалированной" быстрой флэш-память с контролем целостности содержимого, системным областям оперативной памяти отдан физически отдельный (значит - реализованный отдельными микросхемами) диапазон адресов, пользовательскому - отдельный. Это лучшее решение. Все остальные - компромиссные.

Ок. Спасибо за исторический экскурс, я поленился полазить, почитать. Что осталось в памяти от экспериментов с ней в далеком студенчестве, то и писал...

Основное мое возражение, было и осталось, в части применимости в embedded computing. По последнему камменту, подозреваю, что мы по разному понимаем сферы применения. Ведь кроме смартфонов, таблетов, и других консьюмерских девайсов, существует "теневой" рынок профессиональной и производственной embedded техники. Для меня, например, очень актуальная проблема на сегодняшний день - это поиск адекватной замены винды на нечто более embedded, real-time and stable для обеспечения задач измерений в обширной области связанной с прикладной физикой и рядом. С WIN Embedded поигрался, душевно, дешево и сердито. Но реалтаймом, понятное дело, там не пахнет. И очень много уникальных, не стандартных, малосерийных и просто старых девайсов, а работать с ними надо. Апгрейды в производственной сфере, в научных центрах и т.п. происходят очень редко... Уж больно цены там отличаются от консьюмерского рынка...
Так вот, MINIX, насколько я понял из последних release notes, позиционирует себя кандидатом И на это место. И мое мнение, что идеология заложенная в нем, никак не подходит для этих задач. И про "в теме", так к слову, я в этом всем безобразии в юзенете принимал непосредственное участие (в русскоязычном, конечно, там тоже страсти тогда кипели не детские), когда "рождался" Линух, просто я был "на другой" стороне, за монолитное ядро, но, тем не менее, в числе прочих, тоже прочил "скорую смерть идиотcким системам sysv, а уж этой игрушечной операционке, как там её? Linux?...", скорбил по убитой (так тогда все считали) AT&T BSD, тоже рассказывал студентам практически дословно

:-) И SunOS у меня стоял до последнего, и еще год после прекращения Sun-ом его поддержки.

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

Да, кстати, совсем забыл, а как же линуховый rtos? Реально применяемая риалтаймовая ось. Может обзор напишете? Без шуток, у вас здорово выходит.

Самоціль творців вивчати команди dos сподобалася, ги.

> И вот вы этому нечто бодро и радостно в USB-порт
> втыкаете какую-то полезную штуку. Например,
> 3G/4G/WiMax модем

Андрей, это вы насмотрелись моих экзерцисов с Toshiba AC100 и момедом Intellecom?

С одной стороны, там все логично: нет драйверов - нет работы, а драйверов нет потому, что еще никто и никогда не выпускал устройств на этой ОС, к которой потенциально можно было бы подключать такого класса периферию.

С другой стороны, действительно, какой смысл ставить в устройство ОС, под которой гарантировано не заработает 90% периферии, которую, по логике включить в это устройство - самое оно.

именно что, именно что этим.

И вот вы этому нечто бодро и радостно в USB-порт втыкаете какую-то полезную штуку. Например, 3G/4G/WiMax модем. И что просиходит? С вероятностью 90% (а то и все 100%) - системное сообщение "устройство не поддерживается"

Потому что в этом случае можно определить тип подключенного устройства и что сделать? Правильно - подкачать драйвер из какого-то ...store (если он там, конечно, есть)

Это если есть "другой" интернет, иначе получим pkunzip.zip :)

ну хоть wifi уже де-факто стандарт, так что, конечно, pkunzip.zip, но до ближайшей точки доступа

Я конечно скажу глупость, но зачем драйвера выносить в userspace если их всего лишь можно подписать? Т.е. у того же гугла/эйпла (майкрософт это делает давным давно для настольных ОС) появиться дополнительный источник доходов - тестинг и подпись драйверов. А что отдавать в тот же гугл/эйпл/майкрософт на тестинг я думаю разработчики железа договоряться (можно даже и исходники с соответствующей лицензией).

А если будут подписанные драйвера, то можно заводить DriverStore/[System]Update или типа того ресурс и все будут счастливы. Причем для производителей железа будет лишнее маркетинговое преимущество в виде драйверов прошедших тестирование на совместимость с разными железками.

PS. Я б на месте всяких D-Link, ASUS, Cisco посмотрел бы в эту же сторону, а именно официальная поддержка роутерами всяко-разных модемчиков.

PPS. Причем на розничной цене факт такого тестирования особо сказаться не должен (разве что вначале пока кто первый подсуетиться будет сливки снимать).

Linux is like a wigwam - no windows, no gates, aрache inside!

 

Ukraine

 

  •  Home  •  Ринок  •  IТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Мережі  •  Безпека  •  Наука  •  IoT