Узнать PID процесса в драйвере ядра linux

В пространстве ядра есть указатель на текущий процесс - current, который имеет тип struct task_struct *, там есть поле pid, т.е. current->pid вернет pid текущего процесса. А вот где тебе его «ловить»... это уже другой вопрос.

Я сделал так:

int get_my_pid(char *proc_name)
{
        struct task_struct *task;

        for_each_process(task)
        {
                if((strcmp(task->comm, proc_name)==0))
                {
                        user_task = task;
                        return task->pid;
                }
        }
        return -1;
}

int kill_daemon()
{
        int ret = 0;
        struct siginfo info;
        memset(&info, 0, sizeof(struct siginfo));
        info.si_signo = SIGTERM;
        if(user_task > 0)
        {
                ret = send_sig_info(SIGTERM, &info, user_task);    //send the signal
                printk(KERN_ALERT "sent\n");
        }
        if (ret < 0) {
                printk("error sending signal\n");
                return ret;
        }
        return 0;
}

Даже если current->pid у тебя будет не интересующего тебя процесса, то всегда можно «пройтись» по списку процессов, в ядре даже есть макросы для этого, list_for_each например

Как я понял, он хочет оповещать процесс из прерывания — там current нет, т.к. прерывание выполняется вне контекста какого-либо процесса.

В обработчике нужно запоминать значение и отдавать его интересующемуся процессу через системный вызов (убиват!), /proc или файл устройства /dev.

Как я понял, он хочет оповещать процесс из прерывания — там current нет, т.к. прерывание выполняется вне контекста какого-либо процесса.

Да. А я тред по диагонали прочитал.

на моей платформе мне не удалось работать с интервалами меньше системного тика (10 мс)

А задрать частоту не вариант?

еще варианты?

Конечно. Модуль должен реализовывать операцию poll над файловым дескриптором, а пользовательская программа должна вызывать этот poll.

Голосую за какой-нить псевдодевайс в /dev из которого можно читать из юзерспейса. Заодно юзерспейс-программа сможет понять что проспала «такт» если данных окажется больше чем приходит за один интервал.

то есть хочешь сказать, что сделать примерно как с GPIO? Там poll отдаёт POLLPRI при изменении уровня на пине.

то есть хочешь сказать, что сделать примерно как с GPIO?

Я не знаю, как сделано в GPIO :)

Там poll отдаёт POLLPRI при изменении уровня на пине.

Можно и так, но, мне кажется, это не тот случай. Я предпочитаю так, как сделано в RTC: почти нормальный файл, poll ждет готовности к чтению, а read читает нечто (счетчик прерываний или что там устройство может сообщить полезного).

НО! Правильнее всего было бы разобраться с таймерами платформы - ну не верю я, что там есть единственный источник прерываний с частотой всего 100Гц.

А userspace программа не может распознать без таймаута конец кадра ? Там же длина этого кадра в самом кадре забита и контрольная сумма. Пиши все подряд в буфер, а userspace пускай разбирается.

В модбас rtu переменная длина кадра и признаком его окончания служит интервал тишины длительностью 3,5 символа. Так что юзерспейс не разберется.

Задрать частоту чего? Если процессора - то нет, если системного таймера, то на него много чего завязано, я пробовал поднять до 1000 Гц, так не не смог загрузить - ошибки работы с файловой системой.

Вероятно, сделаю как раз через системный вызов, т.к. я изменяю стандартный драйвер uart, и хотелось бы ограничиться минимальными правками. Все равно на коммит мне этот вызов не выставлять.

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

Задрать частоту чего?

Таймера.

я пробовал поднять до 1000 Гц, так не не смог загрузить - ошибки работы с файловой системой.

O_o

А таймер у вас единственный?

Вероятно, сделаю как раз через системный вызов

Welcome to Govnokod land.

Можно и без таймера, выключить передатчик и сделать фиктивную передачу 4 байтов например, получить 4 прерывания, вот и искомый интервал на любой скорости. Вообще не понимаю зачем драйверу этот pid понадобился.

на счет говнокода с вами, к сожалению, полностью согласен(( но пока опыта в ядре мало, а Роберт Лав прочитан лишь один раз, приходится так колхозить( Смысл парится с таймером, если есть АППАРАТНОЕ прерывание по отсутствию новых данных в течение требуемого интервала?

И зачем это делать, если можно посмотреть состояние одного единственного бита и на основании его анализа понять, что произошло то, чего ты ждешь. Лучше делать проще, чем сложнее;) Но за внимание к теме в любом случае спасибо. Я уже сделал говнокод через syscall.

Смысл парится с таймером, если есть АППАРАТНОЕ прерывание по отсутствию новых данных в течение требуемого интервала?

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

А зачем ты тогда системный таймер перепрограммировал, если этот чудо-бит есть ? :)

Хочется же иметь нормальные тайминги (доли миллисекунд), а не куковать аж целых 10 мс)

Communicating between the kernel and user-space in Linux using Netlink sockets http://1984.lsi.us.es/~pablo/docs/spae.pdf

Железка без ОС.