• Моя реализация кольцевого буфера в NOR flash
    +1
    Не хотелось составлять длинный нудный список использованных работ, в конце концов гугл есть у всех.

    А вот этого не могу одобрить. Список литературы — это может быть еще и список рекомендуемый автором к ознакомлению по данной теме.

  • Функция buildargv с помощью Ragel
    +1

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

  • История одного удачного применения SPR в Legacy проекте
    0

    Вы уверены, что это должно быть в хабе "Системное программирование" ?


    system programming

  • Buildroot — часть 2. Создание конфигурации своей платы; применение external tree, rootfs-overlay, post-build скриптов
    0
    Ну вообще да. Просим статью.
  • Buildroot — часть 2. Создание конфигурации своей платы; применение external tree, rootfs-overlay, post-build скриптов
    0
    Но вообще говоря сильно зависит от производителя камня. У texas отличные инструменты для pinmux, NXP тоже догоняет. А вот если плохо с документацией на камень, тогда все очень печально.
  • Buildroot — часть 2. Создание конфигурации своей платы; применение external tree, rootfs-overlay, post-build скриптов
    0
    Ну вот тогда вам и флаг в руки :-D со статьёй. В моей практике не так часто приходится, что-то принципиально новое разводить.
  • Buildroot — часть 2. Создание конфигурации своей платы; применение external tree, rootfs-overlay, post-build скриптов
    0
    Так большинство, по-моему, идет. На самом деле если глянуть, то все SoM, SoC в большинстве своем калька с Evaluation Board.
    Не так уж много делают новых плат — да и зачем.
  • Buildroot — часть 2. Создание конфигурации своей платы; применение external tree, rootfs-overlay, post-build скриптов
    0
    Я вас понял. Да такую статью я бы и сам почитал :-D.
  • Buildroot — часть 2. Создание конфигурации своей платы; применение external tree, rootfs-overlay, post-build скриптов
    0
    А что конкретно в Device Tree вас интересует? Что именно непонятно?
  • Создаём процедурные глобусы планет
    0
  • Пользовательское вознаграждение авторам Хабра
    0
    В порядке бреда — развивая тему:

    1) Ввести возможность ежемесячной платной подписки на хаб.
    2) В рамках определенного периода распределять «призовой фонд» пропорционально вкладу в рейтинг Хаба.
  • Перенос Alpine Linux на RISC-V
    0
    В общем поскольку народ совсем не в теме позволю себе маленькую ремарку:

    — RISC-V это набор ISA (instruction set architecture) открытых спецификаций, которые небходимо соблюдать, что быть RISC-V совместимыми
    — есть открытые реазизации процессоров соответвующих данным спецификациям (открытые — есть код, бери и заливай на FGPA или запекай, участвуй в разработке)
    — доподлинно известно, что микроконтроллеры по RISC-V уже используют NVIDIA и Western Digital
    — Собственно V — означает пятую попытку :-D

    Данная инициатива интересна своей открытостью, то есть все открыто и бесплатно.
  • Перенос Alpine Linux на RISC-V
    0
    Вы просто не в теме. HiFive Unleashed — это первая борда на которую можно поставить Linux. Сами процессоры по RISC-V или залитые на FGPA есть уже давно. Собственно уже есть выбор «микроконтроллеров» на RISC-V.
  • Перенос Alpine Linux на RISC-V
    +1
    Покупали или бесплатно получили?

    Не заметил, что это перевод — прошу пардона.
  • AXIS M3046-V vs IDIS DC-D3212X: Сравниваем камеры видеонаблюдения
    +1
    Очень странно сравнивать:

    AXIS M3046-V: Защита от внешней среды IP42, IK08
    IDIS DC-D3212X: нет

    Потом идем и смотрим AXIS:
    Approvals:
    EMC EN 55032 Class B, EN 55024, EN 61000-6-1,
    EN 61000-6-2, FCC Part 15 Subpart B Class A and B,
    ICES-003 Class B, VCCI Class B, RCM AS/NZS CISPR 22 Class B,
    KCC KN32 Class B, KN35
    Safety IEC/EN/UL 60950-1
    Environment IEC/EN 60529 IP42, IEC/EN 62262 Class IK08, RoHS, WEEE
    Network NIST SP500-267

    Это может быть решающим при выборе.

    У IDIS DC-D3212X не нашёл информацию по этому поводу.

    В общем кто ставит AXIS тот и будет ставить AXIS (как и оборудование Cisco и прочее) потому как корпоративный стандарт (не буду тыкать пальцем, сами знаете кто).

    Для остальных я считаю разница в цене не столь существенна, а для кого существенна, найдут что-нибудь подешевле.

  • Изучаем процессы в Linux
    +9
    image
  • Пишем модуль ядра Linux: GPIO с поддержкой IRQ
    0
    Во-первых, да это закрытая разработка, а во-вторых детальное описание не приводится для того, чтобы не привязываться к конкретной платформе.


    Это очень смелое заявление. Что тогда по-вашему «привязка» к конкретной платформе?
  • Пишем модуль ядра Linux: GPIO с поддержкой IRQ
    0
    Почему слабо — можете посмотреть:

    Драйвер виртуальных GPIO с контроллером прерываний на базе QEMU ivshmem для Linux
    Использование gpio-generic и irq_chip_generic для драйвера gpio
    Заметка о новом интерфейсе linux kernel — gpio uapi

    А пристал я потому, что
    разработанный GPIO блок для нового процессора «зашитый» на ПЛИС

    Без описания этого блока, данная работа лишена смысла. А что за блок? А он открытый? А скачать можно? А какие типы прерываний поддерживает?

    А что за процессор?

    Если все это закрытая разработка, то какой в этом во всем смысл?
  • Пишем модуль ядра Linux: GPIO с поддержкой IRQ
    0
    Так что ваше утверждение о том, что статья не расскрывает вопрос создания драйвера, по моему мнению, очень натянуто.

    То есть вы хотите сказать, что в вашей статье есть что-то новое, что нельзя прочитать в официальной документации?
    https://www.kernel.org/doc/Documentation/gpio/

    Тогда уж многое не упомянуто из того, что там уже есть.
  • Пишем модуль ядра Linux: GPIO с поддержкой IRQ
    +1
    Я хорошо разбираюсь в данной теме. Можете почитать мои статьи. Поэтому и делаю замечания, поскольку ваша статья не раскрывает вопрос создания драйвера, можно открыть любой драйвер gpio поверх mmio и мы получим, более внятное представление, как стоит писать gpio драйвер:

    1) для mmio можно использовать bgpio_init (написанный кстати нашим соотечественником еще аж в 2010 году), и тогда не надо самому писать однотипные в принципе функции write, read, direction и прочие.

    2) для irq в большинстве случаев сгодится irq_chip_generic

    3) Их, простите меня, не «разбивают» на банки они уже по банкам находятся.

    А оправная точка для любого драйвера GPIO, это не подсматривание в готовую реализацию, а вдумчивое изучения документации на железо.
  • Пишем модуль ядра Linux: GPIO с поддержкой IRQ
    +1
    1) Если говорить про принцип создание драйвера с нуля, то стоило бы начать с описания железа и его регистров управления.

    2) Если вы затронули тему идентификации gpio, то стоило бы изучить вопрос с наименованием, вы например в курсе, что экспортированный контакт не обязательно будет иметь имя вида gpioN?

    3) Присутвующие в системе gpio надо смотреть исходя из приципиальной схемы и документации. Номера gpio в системе присваиваються по системе «кто первый встал тог и тапки», это раз, во-вторых номера абсолютно не обязательно идут подряд. Тогда уж надо смотреть base для gpiochip и делать экспорт по числу контактов на чипе, для каждого чипа.
  • Пишем модуль ядра Linux: GPIO с поддержкой IRQ
    –1
    А еще раньше достать такую же железку как у вас…

    То есть стоит написать, что пример не воспроизводим.
  • Получаем данные со счетчиков Меркурий 203.2Т по RS-485
    +2
    Так datasheet говорит, что можно использовать rs485. То есть датчики можно поключить последовательно. Если скорость неважна, то с хорошим кабелем на малой скорости это дает длину шины до 1 км.
  • Вся правда о linux epoll
    0
    Нужно больше материала…

    Если серьезно, я не возьмусь сравнивать, от слова совсем. Это две различные операционные системы, причем я ничего не знаю о FreeBSD.

    Про everything is a file (but not really) — это правда, если начинаешь использовать epoll всегда и везде, как замену select, то точно заметишь. Можно попробовать перефразировать «everything is a file descriptor» — но это тоже не будет правдой.

    Для автора сравнения [1] kqueue статьи важен epoll_ctl — а для меня никогда не было bottleneck, поэтому не берусь судить.

    Так что мы можем сравнить только удобство пользования в каком то смысле, но пускай это делают те кто интересуется кросс-платформенной разработкой.
  • Вся правда о linux epoll
    0
    Принимается.

    Тем более, что EPOLLET был добавлен позже, а не одновременно с epoll.
  • Вся правда о linux epoll
    0
    Вы правы.

    никакого выигрыша не будет никакого существенного выигрыша не будет
  • Вся правда о linux epoll
    0
    In this section we first compare the throughput achieved when using level-triggered epoll with that observed when using select and poll under both the one-byte and SPECweb99-like workloads with no idle connections.

    :-D
  • Вся правда о linux epoll
    0
    >> Ну разумеется poll нельзя научить работать абсолютно так же как epoll, особенно с той же асимптотикой. Но нельзя же говорить что epoll лучше poll просто потому что он epoll!

    Так… А с чего вы решили, что я в статье утверждаю обратное? Я вроде специально акцент сделал на изначальное предназначение epoll и с какой целью он создавался, а потом уже перешел к дополнительным плюшкам.

    Здесь надо акцентировать на том, что epoll по-крайней мере не хуже poll, а в некоторых случаях лучше.

    >> Фича EPOLLET решает ровно одну задачу — дает возможность отложить реакцию на событие и продолжить ждать остальные события. Но poll умеет так же без специальных флагов.

    Именно поэтому я указал на отличие в обработке в ядре, чтобы было еще одно отличие. Собственно из-за это его называют O(1) I/O multiplexer…

    Но если уж быть дотошным, то есть отличия и в правилах merge'a для событий разных типов.
  • Вся правда о linux epoll
    0
    Разобрался, что вы имеете ввиду и честно говоря не нашёл каких-либо противоречий или расхождений с тем, что я рассказал.
  • Вся правда о linux epoll
    0
    Все коннекты активные!

    Figure 3: µserver performance on one byte workload with no idle connections


    Так, что вначале все более ли менее ровно.
  • Вся правда о linux epoll
    +1
    Верно.

    А ядро у нас собирается исключтельно с помощью gcc =).

    И я использую исключительно gcc, но статья о epoll!
  • Вся правда о linux epoll
    0
    Самые первые три графика.
  • Вся правда о linux epoll
    0
    >> необходимость, обусловленная архитектурой epoll
    Вот тут поподробнее пожалуйста, что вы имеете ввиду.

    >> При использовании select/poll аналогичную функциональность можно без труда получить самостоятельно (просто не передавая не до конца обработанные события на вход).

    Разница межде level и edge находиться в ядре. Если c level ядро осуществляет обход каждого дескриптора при вызове epoll_wait, чтобы выснить готов ли дескриптор к обработке. То в edge он пропускает проверку и сразу отправляет вызвавший процесс спать.

    Внешние проявления можно получить безусловно. Но кроме epoll edge умеет только AIO, который кстати вообще обычно никем не рассматривается, даже в обзорных статьях.
  • Вся правда о linux epoll
    0
    del
  • Вся правда о linux epoll
    0
    >> А при 10к дескрипторов, у poll накладные расходы: как минимум копирование 80КБ из user в kernel на каждый вызов. Если честно, с трудом верится, что это не играет существенной роли.

    Всего один syscall =).

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

    Наверное было бы, но это синтетические тесты, я просто знаю что цифр сильно отличных от допустим www.kernel.org/doc/ols/2004/ols2004v1-pages-215-226.pdf, я не получу. А там как раз сравнение poll/select первым идет.
  • Вся правда о linux epoll
    0
    Бесспорно.
  • Вся правда о linux epoll
    –1
    Посмотрел — даже автор там пишет — цитирую:

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


    Но в общем и целом, я не думаю, что это место где стоит обсуждать код ядра линукс. Кто хочет пускай пишет на kernel mail lists, а потом напишет нам, что ему ответили.
  • Вся правда о linux epoll
    0
    Дело в том, что данный момент на таких объемах уже не играет существенной роли (посмотрите 5, 1 из вписка литературы) и это надо понимать.

    Была инересная статья (канула в лета к сожаление) Zed Shaw: «poll, epoll, science, and superpoll» with R, где с цифрами в руках утверждалось, что poll лучше чем epoll.
  • Вся правда о linux epoll
    0
    >> Нет, я имел в виду именно вашу схему (цитата).
    Это момент понятен. Да — можно.
    Хотя я в данном примере просто показывал разницу в поведении edge и level в принципе — не только касательно epoll.

    >> Также отсутствие в собственном коде контроля за временем жизни fd в этом массиве (тоже кстати с линейным временем штука).

    Вот кстати этот момент я в статье не стал затрагивать, поточе что там не все так просто. Да действительно согласно документации при вызове close дескриптор автоматически удалится из отслеживаемых с другой стороны, при специфичных случаях: fork, dup, etc… его необходимо удалять вручную ДО! закрытия.
  • Вся правда о linux epoll
    –1
    А теперь уже растерялся я — а причем тут llvm и ядро linux?