DNIX

Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Поиск источников:  «DNIX»  -  новости  · газеты  · книги  · ученый  · JSTOR ( август 2012 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

DNIX (оригинальное написание: D-Nix ) представляла собой Unix-подобную операционную систему реального времени от шведской компании Dataindustrier AB (DIAB). Версия под названием ABCenix была также разработана для компьютера ABC 1600 от Luxor. ( Daisy Systems также установила что-то под названием Daisy DNIX на некоторых своих рабочих станциях САПР . Это не имело отношения к продукту DIAB.)

История [ править ]

Начало работы в DIAB в Швеции [ править ]

Системные папки для DIAB DS90 и D-NIX

Dataindustrier AB (дословный перевод: компания, владеющая акциями компьютерной индустрии) была основана в 1970 году Ларсом Карлссоном как производитель одноплатных компьютеров в Сундсвалле , Швеция , где производился компьютер на базе Zilog Z80 под названием Data Board 4680 . ^{[ требуется пояснение ]} В 1978 году DIAB начала сотрудничать со шведской телекомпанией Luxor AB по производству домашних и офисных компьютеров серий ABC 80 и ABC 800 .

В 1983 году DIAB независимо разработала первую UNIX- совместимую машину, DIAB DS90, основанную на процессоре Motorola 68000 . Здесь появился D-NIX, основанный на лицензии UNIX System V от AT&T . Однако DIAB была компанией по промышленной автоматизации и нуждалась в операционной системе реального времени , поэтому компания заменила ядро UNIX, поставляемое AT&T, на собственный, но совместимый вариант, работающий в реальном времени. Это ядро ​​изначально было ядром Z80 под названием OS8 . ^[1]

Со временем компания также заменила несколько стандартных инструментов пользовательского пространства UNIX их собственными реализациями, до такой степени, что код не был получен из UNIX, и их машины могли быть развернуты независимо от любой лицензии AT&T UNIX. Два года спустя в сотрудничестве с Luxor был разработан компьютер под названием ABC 1600 для офисного рынка, в то время как параллельно DIAB продолжает производить улучшенные версии компьютера DS90 с использованием более новых версий процессоров Motorola, таких как Motorola 68010 , 68020 , 68030 и в итоге 68040 . В 1990 году DIAB была приобретена Groupe Bull, которая продолжала производить и поддерживать машины DS под торговой маркой DIAB., с такими именами, как DIAB 2320 , DIAB 2340 и т. д., все еще использующие DIAB версию DNIX. ^[2]

Производная в ISC Systems Corporation [ править ]

ISC Systems Corporation (ISC) приобрела право на использование DNIX в конце 1980-х годов для использования в своей линейке банковских компьютеров на базе Motorola 68k . (Позже компания ISC была куплена Оливетти , а затем перепродана Wang , которая затем была куплена Getronics . Это юридическое лицо, чаще всего именуемое «ISC», на протяжении многих лет давало ошеломляющее количество имен.) ветвь кода была версией, совместимой с SVR2 , и подверглась обширным изменениям и развитию. Примечательными особенностями этой операционной системы были поддержка подкачки по запросу , бездисковых рабочих станций , многопроцессорности., асинхронный ввод-вывод , возможность монтировать процессы (обработчики) в каталогах файловой системы и передача сообщений . Его поддержка в реальном времени состояла в основном из внутренних управляемых событиями очередей, а не из механизмов поиска по спискам (без «грохочущего стада» ^[3] ), статических приоритетов процессов в двух классах (выполняемых до завершения и с временным разделением), поддержки смежных файлов (чтобы фрагментация критических ресурсов) и блокировка памяти. Качество ортогональногореализации асинхронных событий еще предстоит достичь в текущих коммерческих операционных системах, хотя некоторые приближаются к этому. (Концепция, которую еще предстоит принять, заключается в том, что точка синхронного распределения всей асинхронной активности сама по себе может быть асинхронной до бесконечности. DNIX справился с этим апломбом.) Функция асинхронного ввода-вывода устраняет необходимость выбора сокетов Беркли или SVR4. «s ПОТОКОВ подушного механизма, хотя была эмуляция сокета библиотека , которая сохраняется гнездовой семантика для обратной совместимости. Еще одной особенностью DNIX было то, что ни одна из стандартных утилит (например, ps , частый преступник) порылся в памяти ядра, чтобы сделать свое дело. Вместо этого использовались системные вызовы, а это означало, что внутренняя архитектура ядра могла изменяться по мере необходимости. Концепция обработчика позволила стекам сетевых протоколов находиться за пределами ядра, что значительно упростило разработку и повысило общую надежность, хотя и за счет снижения производительности. Это также позволило сторонним файловым системам быть процессами на уровне пользователя, опять же для повышения надежности. Основная файловая система, хотя она могла быть (и когда-то была) внешним процессом, была перенесена в ядро ​​по соображениям производительности. Если бы не это, DNIX вполне мог бы считаться микроядром., хотя формально она как таковая не разрабатывалась. Обработчики могут отображаться как любой тип `` собственного '' файла Unix, структуры каталогов или устройства, а запросы ввода-вывода файлов, которые сам обработчик не может обработать, могут быть переданы другим обработчикам, включая базовый, на котором был смонтирован обработчик. . Соединения обработчиков также могут существовать и передаваться независимо от файловой системы, как канал . Одним из следствий этого является то, что «устройства» , подобные TTY, можно эмулировать без необходимости использования псевдотерминального средства на основе ядра .

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

ISC также получила право производить машины DIAB DS90-10 и DS90-20 в качестве файловых серверов. Однако многопроцессорные DS90-20 были слишком дороги для целевого рынка, и ISC разработала собственные серверы и перенесла на них DNIX. ISC разработала собственные бездисковые рабочие станции с графическим интерфейсом пользователя для использования с этими файловыми серверами и снова перенесла DNIX. (Хотя ISC использовала рабочие станции Daisy с Daisy DNIX для проектирования машин, которые будут запускать DNIX DIAB, внутри возникла незначительная путаница, поскольку сотрудники по разработке и макетированию редко разговаривали с сотрудниками по программному обеспечению. Более того, разработчики оборудования не использовали ни одну из систем! шутка пошла что - то вроде: «На ISC мы строить компьютеры, мы не использоватьих. ") Поддержка асинхронного ввода-вывода DNIX позволила легко программировать на рабочих станциях, управляемое событиями , которое работало хорошо, несмотря на относительно ограниченные ресурсы (бездисковая рабочая станция с графическим пользовательским интерфейсом имела процессор 68010 с частотой 7 МГц и могла использоваться только с 512 КБ памяти, из которых ядро ​​занимает примерно половину. На большинстве рабочих станций было 1 МБ памяти, хотя были более поздние версии 2 МБ и 4 МБ, а также процессоры 10 МГц. Полноценная установка может состоять из одного сервера (16 МГц 68020 , 8 МБ ОЗУ и жесткий диск на 200 МБ) и до 64 рабочих станций. Хотя такой массив медленно загружается, такой массив будет приемлемо работать в кассе банка.заявление. Помимо врожденной эффективности DNIX, связанный с ним компилятор DIAB C был ключом к высокой производительности. Он сгенерировал особенно хороший код для 68010 , особенно после того, как ISC покончил с ним. (ISC также перенаправила его на графический сопроцессор Texas Instruments TMS34010, используемый на его последней рабочей станции.) Компилятор DIAB C, конечно, использовался для создания самого DNIX, который был одним из факторов, способствующих его эффективности, и до сих пор доступен (в в какой-то форме) через Wind River Systems .

Эти системы все еще используются на момент написания этой статьи в 2006 году в бывших филиалах Seattle-First National Bank, которые теперь называются Bank of America . Могут быть и, вероятно, есть другие клиенты ISC, все еще использующие DNIX в той или иной степени. Через ISC было значительное присутствие DNIX в Центральной и Южной Америке .

Асинхронные события [ править ]

Собственным системным вызовом DNIX была функция библиотеки dnix (2) , аналогичная стандартной функции Unix (2) или syscall (2) в Unix . Требовалось несколько аргументов, первый из которых был кодом функции. Семантически этот единственный вызов обеспечивал все соответствующие функции Unix, хотя он синтаксически отличался от Unix и, конечно же, имел множество расширений только для DNIX.

Коды функций DNIX были разделены на два класса: Тип 1 и Тип 2. Команды типа 1 были связаны с операциями ввода-вывода или с чем-либо, что могло потенциально вызвать блокировку процесса выдачи. Основными примерами были F_OPEN , F_CLOSE , F_READ , F_WRITE , F_IOCR , F_IOCW , F_WAIT и F_NAP . Тип 2 - это остатки, такие как F_GETPID , F_GETTIME и т. Д. Они могут быть немедленно удовлетворены самим ядром.

Чтобы вызвать асинхронность, необходимо было создать специальный файловый дескриптор, называемый очередью прерываний, с помощью кода операции типа 2 F_OTQ . Вызов Типа 1 будет иметь бит F_NOWAIT, связанный ИЛИ с его значением функции, а одним из дополнительных параметров dnix (2) был дескриптор файла очереди прерываний. Возвращаемое значение из асинхронного вызова было не обычным значением, а идентификатором, назначенным ядром. В тот момент, когда асинхронный запрос завершен, чтение (2) (или F_READ ) дескриптора файла очереди прерываний вернет небольшую структуру, определяемую ядром, содержащую идентификатор и статус результата. F_CANCELоперация была доступна для отмены любой асинхронной операции, которая еще не была завершена, одним из ее аргументов был идентификатор, назначенный ядром. (Процесс мог отменять только те запросы, которые в настоящее время принадлежат ему самому. Точная семантика отмены зависела от обработчика каждого запроса, в основном это означало только то, что любое ожидание должно было быть прекращено. Частично завершенная операция могла быть возвращена.) В дополнение к идентификатор, назначенный ядром, одним из аргументов, передаваемых любой асинхронной операции, был 32-разрядный идентификатор, назначенный пользователем. Чаще всего это ссылка на указатель функции на соответствующую подпрограмму, которая будет обрабатывать метод завершения ввода-вывода, но это было просто соглашение. Это объект, который читал элементы очереди прерывания, отвечал за интерпретацию этого значения.

struct  itrq  {  / * Структура данных, прочитанных из очереди прерываний. * /  short  it_stat ;  / * Статус * /  short  it_rn ;  / * Номер запроса * /  long  it_oid ;  / * ID владельца предоставляется по запросу * /  long  it_rpar ;  / * Возвращаемый параметр * / };

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

Совместимость [ править ]

В дополнение к собственному вызову dnix (2) был доступен полный набор «стандартных» вызовов интерфейса libc . open (2) , close (2) , read (2) , write (2) и т. д. Помимо того, что они полезны для обратной совместимости, они были реализованы двоично-совместимым образом с компьютером NCR Tower , так что двоичные файлы скомпилированы для него будет работать без изменений под DNIX. Ядро DNIX имело два внутренних диспетчера ловушек, один для метода DNIX и один для метода Unix. Выбор диспетчера оставался за программистом, и их взаимозаменяемость была приемлемой. Семантически они были идентичны везде, где функциональность перекрывалась. (В этих машинах 68000 Инструкция trap # 0 использовалась для вызовов unix (2) , а инструкция trap # 4 для dnix (2) . Два обработчика прерываний действительно были очень похожи, хотя [обычно скрытый] вызов unix (2) содержал код функции в регистре D0 процессора, тогда как dnix (2) удерживал его в стеке вместе с остальными параметрами.)

DNIX 5.2 не имел внутренних стеков сетевых протоколов (за исключением тонкого стека протоколов Ethernet на основе X.25 , добавленного ISC для использования его пакетом поддержки бездисковых рабочих станций), вся работа в сети проводилась путем чтения и записи в обработчики. Таким образом, не было механизма сокетов , но существовала библиотека libsocket (3), которая использовала асинхронный ввод-вывод для взаимодействия с обработчиком TCP / IP. Типичная сетевая программа, производная от Беркли, может быть скомпилирована и запущена без изменений (по модулю обычных проблем переноса Unix ), хотя она может быть не такой эффективной, как эквивалентная программа, использующая собственный асинхронный ввод-вывод.

Обработчики [ править ]

В DNIX можно использовать процесс для обработки запросов ввода-вывода и расширения файловой системы. Такой процесс назывался обработчиком и являлся основной функцией операционной системы. Обработчик был определен как процесс, которому принадлежала хотя бы одна очередь запросов , специальный файловый дескриптор, который был получен одним из двух способов: с помощью F_ORQ или F_MOUNT.вызов. Первый изобрел изолированную очередь запросов, один конец которой обычно передавался дочернему процессу. (Сетевые программы удаленного выполнения, которых было много, использовали этот метод для предоставления стандартных путей ввода-вывода своим потомкам.) Последние подключались к файловой системе, так что запросы ввода-вывода файлов могли быть приняты обработчиками. (Программы входа в сеть, которых было еще больше, использовали этот метод для предоставления стандартных путей ввода-вывода своим дочерним элементам, поскольку семантика входа в систему под Unix требует, чтобы несколько, возможно, не связанных между собой процессов подключились к стандартной Путь ввода-вывода к оператору.) После монтирования в каталог в файловой системе обработчик затем получил все вызовы ввода-вывода для этой точки.

Затем обработчик считывает из очереди запросов небольшие структуры данных запроса, назначенные ядром. (Такое чтение может выполняться синхронно или асинхронно, по желанию автора обработчика.) Затем обработчик будет делать все, что требуется для удовлетворения каждого запроса, часто используя вызовы DNIX F_UREAD и F_UWRITE для чтения и записи в пространство данных запроса, а затем будет надлежащим образом завершить запрос, используя F_TERMIN . Привилегированный обработчик мог принять разрешения своего клиента для отдельных запросов к подчиненным обработчикам (таким как файловая система) через вызов F_T1REQ , поэтому ему не нужно было воспроизводить схему разрешений подчиненного. Если обработчик не смог сам выполнить запрос, F_PASSRQфункция может использоваться для передачи запросов ввода / вывода от одного обработчика к другому. Обработчик может выполнить часть запрошенной работы, прежде чем передать остальную работу другому обработчику. Очень часто обработчик был ориентирован на конечный автомат, поэтому все запросы, которые он отправлял от клиента, выполнялись асинхронно. Это позволило одному обработчику одновременно обрабатывать запросы от нескольких клиентов, не блокируя друг друга без надобности. Частью структуры запроса был идентификатор процесса и его приоритет, чтобы обработчик мог выбирать, над чем работать в первую очередь на основе этой информации, не было требования, чтобы работа выполнялась в том порядке, в котором она была запрошена. Чтобы помочь в этом, можно было опросить очереди запросов и ловушек, чтобы увидеть, есть ли еще работа, которую следует рассмотреть, прежде чем приступить к ее выполнению.

struct  ireq  {  / * Структура входящего запроса * /  short  ir_fc ;  / * Код функции * /  short  ir_rn ;  / * Номер запроса * /  long  ir_opid ;  / * ID владельца, который вы дали при открытии или монтировании * /  long  ir_bc ;  / * Счетчик байтов * /  long  ir_upar ;  / * Пользовательский параметр * /  long  ir_rad ;  / * Случайный адрес * /  ushort  ir_uid ;  / * ID пользователя * /  ushort  ir_gid ;  / * Группа пользователей * /  time_t  ir_time ;  / * Время запроса * / ulong  ir_nph ;  ulong  ir_npl ;  / * ID узла и процесса * / };

Не было особых ограничений на количество очередей запросов, которые может иметь процесс. Это использовалось, например, для предоставления сетевых возможностей для chroot- тюрем.

Примеры [ править ]

Чтобы дать некоторую оценку полезности обработчиков, в ISC обработчики существовали для:

• чужие файловые системы
  • ТОЛСТЫЙ
  • CD-ROM / ISO9660
  • файлы образа диска
  • RAM-диск (для использования с загрузочными дисками с защитой от записи)
• сетевые протоколы
  • DNET (по сути X.25 через Ethernet , с возможностью многоадресной рассылки )
  • X.25
  • TCP / IP
  • ДЕКАБРЬ LAT
  • AppleTalk
• удаленные файловые системы
  • DNET / net / machine / path / from / its / root ...
  • NFS
• удаленный вход
  • ncu ( DNET )
  • телнет
  • rlogin
  • wcu ( графический интерфейс DNET )
  • X.25 PAD
  • ДЕКАБРЬ LAT
• удаленное исполнение
  • rx ( DNET )
  • Ремш
  • Rexec
• расширение системы
  • Windowman (графический интерфейс)
  • vterm ( xterm- like )
  • принтер для документов (сберегательной книжки)
  • dmap (аналог ruptime)
  • windowmac ​​(шлюз графического интерфейса для Macintosh)
• системные патчи
  • обработчик именованного канала

Расширения ISC [ править ]

ISC приобрели как 5.2 ( SVR2 совместимый) и 5.3 ( SVR3 совместимые) версии DNIX. На момент покупки DNIX 5.3 все еще находился в стадии разработки в DIAB, поэтому DNIX 5.2 была развернута. Со временем инженеры ISC включили в 5.2 большинство функций ядра 5.3, в первую очередь разделяемую память и IPC , поэтому между DIAB и версиями DNIX ISC было некоторое расхождение в функциях . DIAB 5.3, вероятно, продолжал содержать больше функций SVR3, чем ISC 5.2. Кроме того, DIAB перешел на DNIX 5.4, ОС, совместимую с SVR4 .

В ISC разработчики значительно расширили свою версию DNIX 5.2 (перечислены только функции, связанные с самим ядром ), основываясь как на своих потребностях, так и на общих тенденциях индустрии Unix:

• Поддержка бездисковых рабочих станций. Файловая система ядра рабочей станции была удалена и заменена шлейфом связи Ethernet на основе X.25. Ядро файлового сервера также было расширено сопряженным компонентом, который получал удаленные запросы и передавал их пулу процессов ядра для обслуживания, хотя для этого можно было бы написать стандартный обработчик. (Позже его жизненного цикла продукта, ISC развернутый стандарт SVR4 -На серверов Unix вместо серверов DNIX. Б X.25 ПОТОКИи программа для файлового сервера, написанная на заказ. Несмотря на менее эффективное структурирование, грубая мощность используемых платформ сделала сервер гораздо более быстрым. К сожалению, эта программа файлового сервера не поддерживала все функции собственного сервера DNIX. Такие хитрые штуки, как именованные каналы , вообще никогда не работали. Это было еще одним оправданием для процесса обработчика именованного канала.)
• Поддержка точки наблюдения gdb с использованием функций MMU ISC .
• Реализован асинхронный ввод-вывод в файловую систему. (Первоначально он все равно был заблокирован.) Для этого использовались процессы ядра (kprocs, или потоки).
• Поддержка для truss- или Трассирования -like программы. Помимо некоторого исправления ошибок в стандартном одношаговом механизме Unix ptrace , это потребовало добавления средства временного внедрения процесса, чтобы трассировщик мог использовать стандартный одношаговый механизм для существующих процессов.
• Расширения сигнального механизма SVR4 . В первую очередь для новых сигналов STOP и CONT , но также охватывает и новые вызовы управления сигналами. Из-за отсутствия у ISC исходного кода для отладчиков adb и sdb u-страницу нельзя было изменить, поэтому новые сигналы можно было только заблокировать или обработать по умолчанию, их нельзя было перехватить.
• Поддержка сетевого сниффинга . Это потребовало расширения драйвера Ethernet, чтобы одно событие могло удовлетворить более одного запроса ввода-вывода, и условной реализации аппаратной фильтрации в программном обеспечении для поддержки неразборчивого режима .
• Зеркальное отображение диска . Это было сделано в файловой системе, а не в драйвере устройства, так что несколько (или даже полностью) разные устройства все еще могли быть отражены вместе. Зеркальное копирование небольшого жесткого диска на дискету было популярным способом проверки зеркалирования, поскольку извлечение дискеты было простым способом вызвать дисковые ошибки.
• 32-битный индексный дескриптор , 30-символьное имя файла, символическая ссылка и прикрепленные расширения каталогов к файловой системе. Добавлены устройства / dev / zero, / dev / noise, / dev / stdXXX и / dev / fd / X.
• Списки идентификаторов групп процессов (из SVR4 ).
• #! прямое выполнение скрипта.
• Увеличение числа последовательных портов с помощью коммуникационных плат VMEbus на базе ISC Z-80 .
• Подвижный раздел подкачки.
• Снимки ядра "дамп" запущенных процессов. Поддержка команды fuser .
• Обработка функции renice. Связанная программа изменения приоритетов с разделением времени для реализации плавающих приоритетов.
• Способ «ограбить» процесс, мгновенно лишив его всех ресурсов памяти. Очень полезно для определения текущего рабочего набора , в отличие от того, что все еще доступно для него, но не обязательно используется. Это было связано с утилитой GUI, показывающей состояние всех 1024 страниц карты памяти процесса. (Это количество страниц памяти, поддерживаемых MMU ISC.) При использовании вы периодически «грабите» целевой процесс в течение его жизненного цикла, а затем наблюдаете, сколько памяти было загружено обратно. Это было полезно, поскольку производственная среда ISC использовала только несколько долгоживущих процессов, контроль использования и роста их памяти был ключом к поддержанию производительности.

Функции, которые никогда не добавлялись [ править ]

Когда в 1997 году разработка DNIX в ISC фактически прекратилась, ряд запланированных функций ОС остался в силе:

• Общие объекты. Существовали две динамически загружаемые библиотеки, шифровальщик для DNET и библиотека изображений графического интерфейса пользователя, но это средство никогда не было универсальным. Машины ISC характеризовались общим отсутствием виртуального адресного пространства, поэтому широкое использование отображенных в память объектов было невозможно.
• Облегченные процессы - в самом ядре уже было несколько потоков, которые совместно использовали один контекст MMU, распространение этого на пользовательские процессы должно было быть простым. В API последствия были бы самой трудной частью этого.
• Списки контроля доступа - тривиально реализовать с помощью обработчика ACL, установленного поверх стандартной файловой системы.
• Несколько разделов подкачки - DNIX уже использовал свободное пространство на выбранном томе для подкачки, было бы легко дать ему список томов для проверки по очереди, потенциально с соответствующими ограничениями пространства, чтобы не использовать все свободное пространство на томе раньше. переходя к следующему.
• Удаленная отладка ядра через gdb - все необходимое было для этого либо через обычный последовательный порт, либо через Ethernet с использованием встроенного в ядро ​​программного обеспечения связи X.25, но они так и не были собраны.
• 68030поддержка - прототипы ISC так и не были завершены. Были построены две сменные сменные платы процессоров, но они никогда не использовались как более быстрые 68020. Они не были надежными и не такими быстрыми, как могли бы, из-за необходимости вставляться в гнездо 68020. Модуль MMU ISC с быстрым переключением контекста будет оставлен отключенным (и полностью исключен в предлагаемых производственных единицах), а вместо него должен был использоваться встроенный модуль 68030, использующий производный от кода MMU DS90-20. Хотя модуль MMU ISC был очень эффективным и поддерживал мгновенное переключение между 32 резидентными процессами, его адресность была очень ограниченной. MMU 68030 позволил бы использовать для процесса гораздо больше 8 МБ виртуального пространства, что было пределом для ISC MMU. Хотя этот MMU будет медленнее,общая более высокая скорость 68030 должна с лихвой компенсировать это, так что ожидалось, что машина 68030 будет во всех отношениях быстрее и будет поддерживать гораздо более крупные процессы.

См. Также [ править ]

• Хронология операционных систем
• Cromemco Cromix

Ссылки [ править ]