Hacker News Digest

Тег: #ipc

Постов: 3

OrthoRoute – GPU-accelerated autorouting for KiCad (bbenchoff.github.io)

OrthoRoute — это GPU-ускоренный автотрассировщик плат для KiCad, использующий манхэттенскую решетку и алгоритм PathFinder для работы с высокоплотными платами. Разработанный как плагин KiCad с использованием IPC API, он справляется со сложными проектами с тысячами соединений, которые заставляют традиционные трассировщики сдаться. Проект возник из необходимости: автору требовалась плата с 16 разъемами по 1100 контактов каждый, что составляет 17 600 контактных площадок и 8 192 воздушных соединения для трассировки.

Традиционные автотрассировщики, такие как FreeRouting, показали свою неэффективность — они смогли проложить всего 4% трасс за 7 часов. Вместо того чтобы тратить месяцы на ручную трассировку илиweeks на медленные автотрассировщики, автор решил создать собственное решение. Новая IPC-система плагинов KiCad (версия 9.0) значительно улучшила возможности по сравнению со старой SWIG-системой, обеспечивая лучшую изоляцию процессов, многопоточность и производительность, что делает GPU-программирование более доступным.

by wanderingjew • 18 ноября 2025 г. в 18:54 • 191 points

ОригиналHN

#kicad#gpu#pcb#routing#pathfinding#ipc#multithreading#electronics

Комментарии (21)

  • Пользователь спрашивает о применении платы и её стоимости.
  • Инженер шутит о ручном сверлении отверстий как о стрессовой работе.
  • Автор проекта объясняет, что безработен и делает это как часть экспериментальной идеи, вдохновленной видео.
  • Возникают сомнения в работоспособности платы из-за возможных дефектов в отверстиях.
  • Оценка стоимости платы (A4, 32 слоя) составляет около 1500€ на JLC.

Building a message queue with only two UNIX signals (leandronsp.com)

Автор экспериментирует с созданием простого брокера сообщений, используя только два UNIX сигнала вместо сложных систем вроде Kafka. Он объясняет, что сигналы обычно применяются для управления процессами, но предлагает использовать их для обмена сообщениями. Автор рассматривает различные формы IPC в UNIX, включая каналы, сокеты и файлы, а затем фокусируется на сигналах SIGUSR1 и SIGUSR2, которые являются пользовательскими и могут использоваться для собственных целей.

Основная идея заключается в представлении сообщений как последовательности битов, где каждый бит кодируется соответствующим сигналом (0 - один сигнал, 1 - другой). Это позволяет передавать данные между процессами, используя минимальные системные ресурсы. Автор демонстрирует, как можно "взломать" стандартное поведение сигналов для создания эффективной системы обмена сообщениями, опираясь на двоичное представление данных и возможность перехвата сигналов в коде на Ruby.

by SchwKatze • 20 октября 2025 г. в 22:22 • 116 points

ОригиналHN

#unix#signals#ipc#ruby#message-queue#posix

Комментарии (51)

  • Обсуждение показало, что статья вызвала бурную реакцию: от восторга до критики за clickbait-заголовок и «техническую» неточность.
  • Комментаторы подчеркнули, что UNIX-сигналы не предназначены для передачи данных, не гарантируют очередность и могут терять сигналы при конкурентном доступе.
  • Было отмечено, что вместо сигналов можно использовать уже готовые механизмы, такие как POSIX message queues.
  • Некоторые отметили, что статья может быть интересна как учебный материал, но не как руководство к действию.
  • В итоге, обсуждение показало, что читатели ожидают более честных и точных заголовков и отсутствия сенсационализма, даже в контексте развлекательных экспериментов.

Kernel: Introduce Multikernel Architecture Support (lwn.net)

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

Ключевые компоненты включают расширенную подсистему kexec для загрузки образов, фреймворк межъядерного обмена сообщениями через IPI и механизмы инициализации CPU для x86. Реализация сохраняет обратную совместимость и добавляет интерфейс /proc/multikernel для мониторинга. Пока это черновая версия, требующая тестирования и доработки, но открывающая возможности для zero-down обновлений ядра и новых сценариев изоляции workload'ов.

by ahlCVA • 19 сентября 2025 г. в 15:29 • 181 points

ОригиналHN

#linux#kexec#x86#ipc#dma#pci#acpi#multikernel.io

Комментарии (49)

  • Обсуждаются технические сложности совместного использования аппаратных ресурсов несколькими ядрами, включая управление состоянием драйверов, DMA и аппаратными синглтонами (PCI, ACPI).
  • Проводятся параллели с существующими архитектурами и проектами: exokernel, Barrelfish OS, OpenVMS Galaxy, CoLinux, Kerrighed и LPAR на мейнфреймах IBM.
  • Поднимаются вопросы безопасности: потенциальные уязвимости при совместном доступе к памяти через DMA, отсутствие изоляции между доверенными ядрами и ограниченный периметр атаки при компрометации одного ядра.
  • Отмечаются потенциальные преимущества: улучшенная изоляция сбоев (устойчивость к паникам ядра), высокая производительность без накладных расходов виртуализации и возможность запуска разнородных ОС (Linux и BSD).
  • Упоминается коммерческий контекст: автор работает над этим в рамках стартапа multikernel.io, что вселяет надежду на понимание производственных сложностей.