Реферат по теме выпускной работы

Содержание

Введение 1. Актуальность темы 2. Цель и задачи исследования, планируемые результаты 3. Современное состояние проблемы 3.1 Сравнение существующих системных утилит для работы с файловой системой 4. Исследование возможностей UEFI по работе с дисковыми устройствами, файловыми системами и файлами 5. Исследование возможностей UEFI по работе с графикой и видео, для разработки графического пользовательского интерфейса Выводы Список источников

Введение

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

1. Актуальность темы

Разработка файлового менеджера в виде UEFI приложения, позволяет успешно решать задачи по управлению файлами и каталогами, на устройстве с неисправной операционной системой или полностью без неё. Благодаря платформе UEFI данное приложение будет успешно работать на любой аппаратной платформе. В некоторых случаях даже без перекомпиляции приложения [1].

2. Цель и задачи исследования, планируемые результаты

Целью магистерской диссертации является исследование и разработка системной утилиты файлового менеджера для работы с файловой системой с использованием возможностей платформы UEFI.

Для достижения поставленных целей, необходимо выполнить следующие задачи:

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

3. Современное состояние проблемы

Современные системые утилиты способные функционировать без операционной системы в основном реализованы с использованием операционной системы MS-DOS. Системные утилиты разработанные в качестве приложений MS-DOS обладают следующими существенными недостатками: отсутствие кроссплатформенности, работа приложения в реальном режиме процессора, ограничение доступной оперативной памяти в 1 мегабайт, наличие только консольного интерфейса, однозадачность, отсутствие поддержки нового оборудования и отсутствие поддержки сети. Компания Intel заявила, что в 2020 г. откажется от поддержки модуля CSM, который обеспечивает совместимость со старыми системными утилитами которые не поддерживают UEFI. В результате этого использование системных утилит работающих в качестве приложений MS-DOS станет невозможным [2].

Системная утилита для работы с файловой системой должна обладать базовыми возможностями при работе с файлами. Для выполнения данной задачи утилита должна выполнять: чтение таблицы разделов с диска, чтение и запись файлов в файловой системе, базовые манипуляции с файлами такие как переименование, перемещение и т. д. Рассмотрим существующие системы утилиты для работы с файловой системой.

3.1 Сравнение существующих системных утилит для работы с файловой системой

3.1.1 Volkov Commander

Файловый менеджер Volkov Commander, клон файлового менеджера Norton Commander разработанный Всеволодом Волковым, выпущен в 1994 году и обладает всеми базовыми возможностями [3]. Утилита разрабатывалась с использованием языка ассемблера. Работает в среде операционной системы DOS. Является условно-бесплатным программным обеспечением c закрытым исходным кодом.

3.1.2 Grub2 File Manager

Файловый менеджер в виде UEFI приложения использующийся для загрузки различных образов дистрибутивов операционных систем. Впервые исходный код утилиты опубликован в феврале 2020 года и распространяется по лицензии GPL-3.0. Обладает ограниченными возможностями по работе с файлами и каталогами [4].

4. Исследование возможностей UEFI по работе с дисковыми устройствами, файловыми системами и файлами

Доступ к файловому вводу-выводу обеспечивается при помощи протокола EFI_FILE_PROTOCOL к поддерживаемым файловым системам. Он обеспечивает доступ к содержимому файла или каталога, а также является ссылкой на место в дереве каталогов файловой системы, в которой находится файл [5]. С любым указанным дескриптором файла, другие файлы могут быть открыты относительно местоположения этого файла, давая новые дескрипторы.

При запросе протокола файловой системы на устройстве получается протокол EFI_FILE_PROTOCOL для тома. Этот интерфейс используется для открытия корневого каталога файловой системы при необходимости. Программа должна закрывать дескриптор файла при помощи функции Close() для корневого каталога и любых других открытых файловых дескрипторов перед выходом. Пока на устройстве есть открытые файлы, следует избегать использования базовых протоколов устройства, которые абстрагируются файловой системой. Например, протоколов EFI_DISK_IO_PROTOCOL или EFI_BLOCK_IO_PROTOCOL.

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

Работа с файлами выполняется при помощи различных функций. Такие функции как Open() и Close() выполняют открытие и закрытие файла. Функции Read(), Write() обеспечивают операции побайтового чтения и записи. Также протокол имеет различные вспомогательные функции, которые упрощают работу и взаимодействие с файлами.

5. Исследование возможностей UEFI по работе с графикой и видео, для разработки графического пользовательского интерфейса

Системные утилиты, обладающие графическим пользовательским интерфейсом, являются более простыми и дружелюбными в использовании. Для использования графических возможностей, UEFI предоставляет программную абстракцию, которая позволяет поддерживать любое графическое оборудование [6]. Однако, возможны особенности реализации на других платформах [7].

Спецификация EFI определяет протокол UGA (Universal Graphic Adapter, универсальный графический адаптер) как независимый от устройства способ поддержки графики. UEFI не содержал UGA и заменял его GOP (Graphics Output Protocol) с явной целью удаления аппаратных зависимостей VGA (Video Graphics Array). UEFI версии 2.1 определил «Инфраструктуру интерфейса пользователя» (HII, Human Interface Infrastructure) для управления вводом пользователя, локализованными строками, шрифтами и формами при помощи HTML. Это позволяет разрабатывать графические интерфейсы для приложений поставляемые вместе со встроенным программным обеспечением. Самые ранние реализации встроенного микропрограммного обеспечения UEFI были консольными. Сегодня многие реализации UEFI имеют графический интерфейс.

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

Основной графической операцией в EFI_GRAPHICS_OUTPUT_PROTOCOL является передача блока или BLT. Операция BLT позволяет считывать или записывать данные в видеопамять видеоадаптера. Операция BLT абстрагирует аппаратную реализацию видеоадаптеров, предоставляя концепцию программного буфера BLT.

Буфер кадров представляет кадр в виде массива пикселей. Расположение каждого пикселя на экране определяется его координатами x и y. Координата x представляет линию сканирования (горизонтальная линия пикселей на дисплее). Координата y представляет вертикальную линию на дисплее. Верхний левый угол видеодисплея имеет координаты (0, 0), нижний правый угол дисплея представлен (ширина - 1, высота - 1). Изображение программного буфера Blt представлено на рисунке 4.

Программный буфер Blt структурирован как массив пикселей. Pixel (0, 0) является первым элементом программного буфера Blt. Буфер Blt можно рассматривать как набор строк сканирования. Местоположение пикселя на экране преобразуется в элемент буфера Blt, используя следующую формулу: индекс элемента буфера BLT = y * width + x, где width – ширина, x и y – координаты пикселя на экране [8].

Каждая запись в программном буфере Blt представляет собой пиксель, состоящий из 32-битного значения. Компоненты цвета пикселей буфера Blt имеют формат PixelBlueGreenRedReserved8BitPerColor, который определён в структуре EFI_GRAPHICS_OUTPUT_BLT_PIXEL. В соответствии с этим форматом нулевой байт представляет синий цвет, первый байт зелёный цвет, второй байт синий цвет, а третий зарезервирован. Значения байтов для красного, зеленого и синего компонентов цвета являются его интенсивностью. Это значение интенсивности цвета варьируется от минимальной 0 до максимальной интенсивности 255.

Протокол предоставляет следующие вспомогательные функции с именами QueryMode, SetMode и Blt. QueryMode() – функция возвращает информацию о доступном графическом режиме, который поддерживает графическое устройство и набор активных устройств вывода изображения. SetMode() – функция устанавливает видеоустройство в указанный режим, заданный параметром, и очищает видимые части выходного дисплея закрашивая в черный цвет. Blt() – функция используется для выполнения операции, определяемые параметром BltOperation с переданным буфером Blt и экраном. В таблице 1 описаны все поддерживаемые операции Blt.

Протокол EFI_GRAPHICS_OUTPUT_PROTOCOL предоставляет эти базовые возможности без использования графического драйвера операционной системы. Программное обеспечение, использующее графику в среде современных операционных систем, задействует видео ускоритель, минуя функции BIOS [9]. В то же время, программист, использующий функции встроенного программного обеспечения UEFI для работы с графикой, лишен такой возможности. Он должен выполнять запись в видео память средствами центрального процессора, следуя методологии VESA BIOS Extension, либо вызывать прерывание INT 10h для вывода каждого пикселя [10].

Благодаря продвинутой функции BLT или Block Transfer, реализованной в рамках Graphics Output Protocol, потенциально дает возможность использовать видео ускоритель. Блок данных, находящийся в системной памяти и предназначенный для переноса в видео память может быть обработан графическим процессором, взаимодействующим с оперативной памятью в режиме Bus Master. Чтобы это стало возможным, поддержка протокола Graphics Output Protocol должна быть адаптирована к архитектуре конкретного графического процессора и интегрирована в микропрограмму, которая расположена в видеоадаптере. Такая ситуация делает устаревшие функции Legacy BIOS не требуемыми.

Выводы

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

Список источников