Рейтинг@Mail.ru

Наши друзья и партнеры

UnixForum
купить дешевый 
компьютер родом из Dhgate.com




Библиотека сайта rus-linux.net

Проект GPSD

Глава 7 из книги "Архитектура приложений с открытым исходным кодом", том 2.
Оригинал: GPSD, глава из книги "The Architecture of Open Source Applications" том 2
Автор: Eric Raymond
Перевод: Н.Ромоданов

7.6. Нет конфигурирования — нет суеты

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

Если в операционной системе, в которой установлен демон, есть возможность горячего подключения, то скрипты горячего подключения могут отправлять сообщения об активации и деактивации устройств в управляющий сокет, который уведомит демон об изменении в его окружении. В дистрибутиве GPSD такие скрипты поставляются для Linux. Результатом является то, что конечные пользователи могут подключить USB-устройство GPS к своему ноутбуку и ожидать, что оно немедленно начать передавать сообщения, которые смогут прочитать приложения, определяющие местоположение - без путаницы, без суеты и без редактирования настроечного файла или реестра свойств.

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

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

Разработчики GPSD являются специалистами системы Unix, работающими согласно глубоко укоренившейся традиции Unix, согласно которой конфигурационные средства и наличие большого количества регуляторов близко к религии. Тем не менее, мы думаем, что в проектах с открытым исходным кодом можно попытаться сделать намного больше, выбросив настроечные файлы и автоматически выполняя конфигурирование в в зависимости от того, в какой среде происходит действие.

7.7. Ограничения, имеющиеся во встроенных системах, полезны

С 2005 года основной задачей проекта GPSD были разработки встраиваемых систем. Первоначально это было связано с тем, что в нас были сильно заинтересованы системные интеграторы, работающие с одноплатными компьютерами, но затем это проявилось неожиданным образом: установками на смартфонах с поддержкой GPS. Однако, согласно отчетам нашими самыми любимыми встроенными системами все еще остаются роботы-подводные лодки.

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

Одним из важных аспектов в этом вопросе является, как уже упоминалось, возможность обеспечивать, чтобы в сборках gpsd не было ничего лишнего, кроме определенного набора протоколов для датчиков, которые должен поддерживать системный интегратор. В июне 2011 года для минимальной статической сборки gpsd для системы x86 необходим был объем памяти равный приблизительно 69K (это со прикомпонованными необходимыми стандартными библиотеками на C) на 64-разрядной архитектуре x86. Для сравнения, статическая сборка со всеми драйверами равна приблизительно 418K.

Другая особенность состоит в том, что мы профилируем хотспоты CPU несколько иначе, чем в большинстве проектов. Поскольку датчики месторасположения, как правило, передают лишь небольшие объемы данных с интервалом порядка 1 секунды, производительность в обычном смысле не является проблемой для проекта GPSD - даже крайне неэффективный код вряд ли будет настолько увеличивать задержки, что они будут видны на уровне приложений . Вместо этого, наши усилия направлены на уменьшение использования ресурсов процессора и сокращение энергопотребления. В этом вопросе мы оказались довольно успешными: даже на маломощных системах ARM без FPU, доля ресурсов процессора, потребляемая gpsd, была снижена приблизительно до уровня шума, вносимого профилировщиком.

Хотя разработка кода, мало занимающего память и с хорошей энергоэффективностью, является в данный момент в значительной степени решенной проблемой, есть еще один аспект, стремление к которому во встроенных системах все еще создает напряженность в архитектуре GPSD: использование скриптовых языков. С одной стороны, мы хотим минимизировать дефекты, связанные с низким уровнем управления ресурсами, удаляя из языка C столько кода, сколько это возможно. С другой стороны, язык Python (предпочитаемый нам скриптовый язык) для большинства встроенных систем просто слишком тяжеловесен и медлителен.

Мы решаем этот компромисс очевидным образом: демон сервиса gpsd написан на языке C, в то время как фреймворк тестирования и несколько утилит поддержки написаны на языке Python. Со временем, мы надеемся перенести большую часть вспомогательного кода из C в Python, но из-за встроенных систем такие решения становятся источником постоянных противоречий и неудобств.

Тем не менее, в целом мы считаем, что влияние встроенных систем делает код достаточно прочным. Оно хорошо чувствуется в том, что пишется рациональный компактный код, который экономно использует ресурсы процессора. Говорят, что искусство создается благодаря творчеству в условиях ограничений; под таким влиянием GPSD действительно становится лучшим.

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


7.8. JSON и архитектонавты

Если вам понравилась статья, поделитесь ею с друзьями: