Продолжим рассматривать ошибки, которые удалось обнаружить в проекте Miranda NG с помощью статического анализатора кода PVS-Studio. В прошлый раз мы говорили об указателях и работе с памятью. Теперь поговорим об ошибках общего плана, которые, в основном, связаны с неаккуратностью и опечатками.

Продолжаем изучать планирование маленьких потоков. Я уже рассказала про два средства в ядре Linux, которые часто используются для отложенной обработки прерываний. Сегодня речь пойдет о совсем другой сущности — protothread Adam Dunkels, которые хоть и выбиваются из ряда, но в контексте рассматриваемой темы совсем не лишние.

А также:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

Продолжаем тему многопоточности в ядре Linux. В прошлый раз я рассказывала про прерывания, их обработку и tasklet’ы, и так как изначально предполагалось, что это будет одна статья, в своем рассказе о workqueue я буду ссылаться на tasklet’ы, считая, что читатель уже с ними знаком.
Как и в прошлый раз, я постараюсь сделать мой рассказ максимально подробным и детальным.

Статьи цикла:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

Я добрался до проекта Miranda NG и проверил его с помощью анализатора кода PVS-Studio. К сожалению, с точки зрения работы с памятью и указателями это самый неаккуратный проект из виданных мной. Хотя я внимательно не анализировал результаты, ошибок столь много, что я решил разбить собранный материал на 2 статьи. Первая статья будет посвящена указателям, а вторая всему остальному. Желаю приятного чтения, и не забудьте взять попкорн.

В предыдущей своей статье я затронула тему многопоточности. В ней речь шла о базовых понятиях: о типах многозадачности, планировщике, стратегиях планирования, машине состояний потока и прочем.

На этот раз я хочу подойти к вопросу планирования с другой стороны. А именно, теперь я постараюсь рассказать про планирование не потоков, а их “младших братьев”. Так как статья получилась довольно объемной, в последний момент я решила разбить ее на несколько частей:

1. Многозадачность в ядре Linux: прерывания и tasklet’ы
2. Многозадачность в ядре Linux: workqueue
3. Protothread и кооперативная многозадачность

В третьей части я также попробую сравнить все эти, на первый взгляд, разные сущности и извлечь какие-нибудь полезные идеи. А через некоторое время я расскажу про то, как нам удалось применить эти идеи на практике в проекте Embox, и про то, как мы запускали на маленькой платке нашу ОС с почти полноценной многозадачностью.

Рассказывать я постараюсь подробно, описывая основное API и иногда углубляясь в особенности реализации, особо заостряя внимание на задаче планирования.

RSA является широкоизвестным алгоритмом шифрования с открытым ключом. На его основе, кроме асимметричного шифрования, можно также реализовать электронную подпись (ЭЦП). Эти возможности привлекательны для встраиваемых систем, микроконтроллеров. Сам метод шифрования с виду чрезвычайно прост:

C = (Me) mod n

(1)

где C,M,e,n — целые числа, M — открытый текст, числа e и n представляют собой открытый ключ, C — шифротекст. mod — остаток от деления.

Расширование выглядит столь же просто:

M = (Cd) mod n

(2)

где C,M,n играют ту же роль, что и при шифровании, d — закрытый ключ.

При этом n=p*q, где p и q — простые числа (секретные), e обычно равно 65537, d вычисляется на основе e, p и q. Криптостойкость основана на том, что для достаточно больших p и q задача разложения n на множители или обращения формулы шифрования без знания p и q не решается за приемлемое время.

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

Израильская компания Starcom Systems специализируется на различного рода GPS/GSM трекерах и удаленных системах контроля, базирующихся на них. В данном случае ко мне попало разработанное в этой компании устройство: электронный замок с функциями GPS-трекера WatchLock, который Starcom выпускает совместно с компанией Mul-T-Lock.

Устройство совмещает в себе функции классического навесного замка с функциями GPS/GSM трекера и соответственно позволяет контролировать такие параметры как: открытие/закрытие замка, физическое воздействие на замок (при помощи акселерометра), текущие местоположение замка и т.д. Передача информации о событиях посредством сети GSM. Возможно использовать для связи два варианта, GPRS канал и(или) SMS сообщения (в данном случае связь через SMS меня не особо волнует, поэтому остановимся на GPRS). Передача данных ведется на сервер компании или на прокси-сервер, установленный у дилера на поддерживаемый дружественный сервис. Например, Wialon, либо опять таки на сервер компании. Частному пользователю, купившему устройство для личных нужд, не удастся его использовать без оплаты услуг сторонних компаний, что для не корпоративных пользователей может быть накладно или излишне (либо, как вариант, необходима высокая анонимность). Я один из тех, кому функционал больших мониторинговых серверов излишен, а возможность поиграться с новым устройством мотивационна. Итак, приступим!

В любом среднем или крупном приложении, будь оно desktop или web, для бизнеса или для личного пользования, программисту необходимо решить важную архитектурную задачу — как будут общаться между собой потоки, процессы, модули, ноды, кластера, и прочие части эко-системы его приложения.

Многие разработчики решают идти по пути наименьшего сопротивления, возложив эту задачу, например, на СУБД. Скажем, один процесс положил данные в БД, второй прочитал, обработал — положил еще и так далее.
Про обмен через файлы в наши годы уже стыдно говорить, но и такое случается.
Другие же программисты пытаются создать какое-то свое, специализированное решение и, как правило, выбирают сокеты.

Задача проектирования и разработки архитектуры приложения крайне интересная, но это отдельная тема. В данном посте хотел бы поделиться своим первым впечатлением от знакомства с библиотекой ZeroMQ.

ZeroMQ предлагает разработчику некий высокий уровень абстракции при работе с «сокетами». Библиотека берет на себя часть забот по буферизации данных, обслуживанию очередей, установлению и восстановлению соединений, и прочие вещи. Вместо того, чтобы заниматься такими глупостями, вы можете сосредоточиться на главном — архитектуре и логике приложения.

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

Разработка электроники на базе GPS/ГЛОНАСС-технологий — одна из наших любимых тем на Хабре. Мы уже писали обзорную статью на эту тему, рассказывали про систему «ЭРА-ГЛОНАСС» и даже определяли своё местоположение по сетям сотовой связи.

В этот раз наш пост призван дать ответ на конкретный практический вопрос: «Как уменьшить объем потока данных с навигационно-связных терминалов без потери информативности?». Эта тема весьма актуальна, ведь услуги беспроводной связи составляют значительную часть финансовых затрат на обслуживание систем мониторинга транспорта.

Для начала давайте посмотрим, что представляет собой тракт подготовки и сбора информации на терминалах перед отправкой данных на сервер.

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

Собственно через регулярные выражения я к ним и пришёл.

Целью данной работы является получение кода, сгенерированного бэк-эндом компилятора LLVM MSP430

Введение

CLANG — это просто фронт-энд компилятора С для LLVM. LLVM — это фреймворк для разработки фронт-эндов, бэк-эндов компиляторов для разных целевых платформ. Этот фреймворк облегчает анализ путем приведения всех фронт-эндов к промежуточному представлению (IR). Все бэк-энды оперируют с этим общим представлением.

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

Текущая поддержка MSP430 весьма ограничена. Я надеюсь, что смогу помочь кому-нибудь, кто слишком фейс-палмит, сохранить лицо. ¹

Поехали

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

“А какой материал вы собираетесь размещать в корпоративном блоге, вы же не ИТ-компания?” – именно такой вопрос нам задали, когда мы обратились в Habrahabr с просьбой открыть корпоративный аккаунт. И в очередной раз убедились, что пора выходить из тени, и рассказывать о том, что любая биржа — и Московская Биржа в том числе – это, в первую очередь, высокотехнологичная компания со своими торгово-клиринговыми системами, продвинутой IT-инфраструктурой, масштабными разработками и широким набором различных сервисов.

Успешная работа большинства крупных компаний зависит от IT-разработок, в частности, их современности, надежности и производительности. Для примера, в среднем до 30% сотрудников ведущих мировых бирж – это IT-специалисты, занятые разработкой торговых платформ, их сопровождением, а также аппаратной части. И Московская Биржа полностью в тренде.

Биржа – это торговая площадка, основная задача которой – чтобы конечный клиент купил или продал необходимый ему объем актива по устраивающей его цене, в определенный им самим момент времени, и гарантированно получил этот актив на свой счет депо или денежные средства от его продажи на свой расчетный счет.

Любая из всех вышеперечисленных процедур сегодня происходит в электронном виде.

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

Хотя на самом-то деле, если вспомнить историю Си, всё достаточно очевидно и, главное, логично. А все жалобы людей, «обжёгшихся» на неопределённом поведении для людей не забывших что такое Си и зачем он вообще существует звучат примерно как: «я тут гвозди бензопилой забивал… забивал и забивал, всё было хорошо, а потом я дёрнул за ручку и у неё коготки как забегают, задёргаются, мне руку оттяпало и полноги… ну кто так строит?».

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

После прочтения книги Test Driven Development for Embedded C я начал знакомство с миром юнит-тестирования с фреймворка cppUtest. Не в последнюю очередь потому, что в нем свеженаписанный тест регистрируется и запускается самостоятельно. За это приходится платить — использованием C++, динамическим выделением памяти где-то в глубинах фреймворка. Может быть, можно как-то попроще?
Совсем недавно я узнал о минималистичном фреймворке minUnit, который умещается всего в 4 строчки.

Network Security Services (NSS) — это набор библиотек, разработанных для поддержки кроссплатформенной разработки защищенных клиентских и серверных приложений. Библиотека используется для криптографии в браузерах Firefox и Chrome, и после недавно найденной уязвимости в проверке подписей сертификатов, я решил тоже взглянуть на этот проект.

Картинка для привлечения внимания

Как известно, Caché это не только СУБД, но и полноценный язык программирования (Caché ObjectScript). И со стороны СУБД, и со стороны Caché ObjectScript (COS) доступ за пределы Caché богат возможностями (в .Net/Java через .Net/Java Gateway, к реляционным СУБД через SQL Gateway, работа с веб-сервисами). Но если говорить о работе с нативными бинарными библиотеками, то такое взаимодействие реализуется через Caché Callout Gateway, который несколько специфичен. О том как радикально облегчить работу с нативными библиотеками непосредственно из COS можно узнать по катом.

Есть у меня несколько проектов-долгостроев, один из которых — создание компьютера на базе CDP1802. Основную плату моделировал на бумаге и в Proteus.
Довольно скоро встал ребром вопрос: как быть с элементами, которые отсутствуют в Proteus?
На многих ресурсах подробно описано, как создать свою модель на С++ в Visual Studio.
К сожалению, при сборке под линуксом этот вариант не очень удобен. Да и как быть, если не знаешь С++ или нужно редактировать модель на лету для отладки?
Да и просто хочется сосредоточиться на моделировании, максимально упростив все остальное.
Так появилась идея делать симуляторные модели с помощью скриптов — на Lua.
Заинтересовавшихся прошу под кат (гифки на 2Мб).

Простой макрос

Все началось с простого макроса: (приблизительный код)

#define ADD_BYTE(C) do {            \
  if (offset == capa) {             \
    if (capa < 16) {                \
      capa = 16;                    \
    } else {                        \
      capa <<= 1;                   \
    }                               \
    buffer = realloc(buffer, capa); \
    assert(buffer != NULL);         \
  }                                 \
  buffer[offset++] = (C);           \
} while(0)

Для тех, кто не знаком с языком программирования C, поясню: этот простой макрос добавляет байт «C» в динамически выделяемый буфер (buffer), размер которого (в байтах) равен capa. Следующая позиция для записи определяется при помощи параметра offset. При каждом заполнении буфера происходит двукратное увеличение его объема (начиная с минимального размера в 16 байт).

Мы добавляем байты в динамический буфер — это одна из наиболее распространенных операций практически в любой программе (для работы со строками, массивами и т. п.).

Но как понять, насколько эффективна стратегия перераспределения?

Авторы анализатора PVS-Studio предлагают вам проверить свою внимательность.

Анализаторы кода работают без устали и умеют находить множество ошибок, которые сложно заметить. Мы отобрали некоторые фрагменты кода, в которых мы выявили ошибки с помощью PVS-Studio. Все фрагменты взяты из известных Open-Source проектов.

Предлагаем вам посоревноваться с анализаторами в прозорливости и попробовать самостоятельно найти ошибки. Вам будет предложено 15 случайно выбранных заданий. За верный ответ насчитывается одно очко, если он дан в течение 1 минуты. Фрагменты кода короткие, и 1 минута это честное ограничение.

Приветствую, уважаемый хабраюзер.

Начну с небольшой предыстории. В данный момент я работаю над довольно комплексным продуктом, который состоит из серверной части (включает в себя несколько сервисов) и клиентского SDK, портированного на определенные платформы. Весь этот зоопарк нам надо каким-то образом тестировать совместно.

Были сделаны клиентские приложения (своего рода драйверы), которые используют соответствующие SDK и умеют получать команды от тестирующего сервиса вида «сходи на сервер, сделай то», или «дай мне такой-то результат для проверки». Команды клиент получает, используя Thrift(wiki). И все было хорошо, пока мы не добрались до портирования SDK на Си и не обнаружили, что толкового мануала для Си у Apache'а нету. Нашли тикет на создание оного мануала и скудный пример там же. После успешного применения Thrift'а в Си, было решено написать небольшой ликбез на эту тему.

Цели, которые мы поставили:
— Клиент должен получать команды от тестирующего сервиса, используя Thrift;
— Команды это отлично, но нужно еще и с сервером общаться;
— Клиент должен работать в одном потоке.