LINUX.ORG.RU
Форум — Development  

использование одного ttyS0 двумя разными процессами

 , ,


0

1

Всплыла следующая проблема.
Есть некая плата на ARM. Там крутится линукс. На плате есть последовательный порт ttyS0. Сейчас этот порт используется как системная консоль (туда u-boot пишет, ядро, agetty и т.д.). Кроме этого на плате есть спец. прога, которая вешается на последовательный порт, ждет прихода команд и отправляет умные ответы взад.
Первый пробный запуск с портом ttyS0 показал, что в реальности это работает как-то кривовато (проверка на втором порту показала, что спец.программа работает корректно).
Внимание вопрос. Как сделать так чтобы перед запуском спец.программы, все остальные программы (ядро и agetty) либо отвалились от порта, ну или пересели на другой. Нужен именно такой вариант, а не всех сразу рассадить по разным портам.

★★★★★
← string «to_a» в Ruby 1.9 неизвестный метод
Как запретить parent процессам передавать сокеты child процессам? →

демон-владелец портов и протокол общения с демоном решит проблему

anonymous
()

есть подозрение, что никак...

В свое время задавал похожий вопрос на форуме производителей своей платы с линуксом - мне предложили установить переменные окружения в u-boot. Понятно, что такой способ не сработает

перед запуском спец.программы

solovey ★★
()
Ответ на: комментарий от solovey

Пока ехал домой немного помозговал.
agetty я думаю смогу отвязать, после таймаута его можно просто тупо убить (главное чтобы его никто не рестартанул).
А вот что делать с ядром пока не ясно.

yax123 ★★★★★
() автор топика

Кури /etc/inittab, если используется busybox, там скорее всего есть что-то вроде 

# Run a shell on the first serial port. Comment out if you want a getty instead.
ttyS0::respawn:-/bin/sh

# Uncomment this to run a getty on the first serial port.
ttyS0::respawn:/sbin/getty -L ttyS0 115200 vt100
Комментируешь нужное и getty тебя больше не беспокоит. Ядро использует debug serial console обычно только во вовремя загрузки. Если же это не так, то нужно править код инициализации твоей борды в arch/arm/mach-<name>/<yourboard>.c на предмет комментирования привязки к debug console.

m0rph ★★★★★
()
Последнее исправление: m0rph (всего исправлений: 1)
Ответ на: комментарий от yax123

С agetty разобрался: 

s0:12345:once:/sbin/agetty -t 3 115200 ttyS0 vt100
Так же можно обойтись без таймаута и просто в нужный момент его убивать.

А вот с ядром пока не ясно. Еще есть опасения насчет всяких klogd и syslogd, они же тоже могут в экстренных случаях гадить в порт.

yax123 ★★★★★
() автор топика
Ответ на: комментарий от yax123

с ядром пока не ясно

Можно просто повесить на другой порт.

Как я уже писал, мне на форуме разработчики железки предложили в u-boot задать следующие переменные: 

setenv stdout serial1
setenv stderr serial1
setenv stdin serial1

solovey ★★
()
Ответ на: комментарий от solovey

Нужно чтобы все было на одном. Чтобы подключился к железке, сбросил ее и смотришь, что там в u-boot происходит (и в случае чего там поковырялся), потом смотрим как там грузится ядро. Доходит до приглашения логина, там 3-5 сек таймаут, и если ничего нет то agetty просто завершает работу, освобождая порт (это он уже из коробки сам может). А вот как ядро отвязать непонятно.

yax123 ★★★★★
() автор топика
Ответ на: комментарий от Elyas

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

yax123 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← string «to_a» в Ruby 1.9 неизвестный метод
Development
Как запретить parent процессам передавать сокеты child процессам? →