Опыт разработки драйверов периферии, сброки, конфигурирования и embedded есть, также большой опыть разработки на С/C++

не стесняйся, давай ссылки

Нейросетка не в состоянии просмотреть заголовки топиков в разделе, в который постит.

Это частные проекты под embedded, где, в основном, требовалась кастомизация ядра под конкретно железо. В основном на ARM926

Он наверное хочет наставника за денежку.

конкретика, сестра. нужна конкретика

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

Так почти никто и не работает. «Разработка комьюнити» — это миф.

большой опыть разработки на С/C++

Так на С или С++?

Может возьмете к себе под ваше наставничество или дадите реальные задачи

Можешь попробовать помочь https://www.openwall.com/lkrg/, или другим подобным проектам.

Нафиг тебе ядро? Вон, куча проектов нуждается в ТВОЕЙ поддержке.

Пройди сначала eudyptula challenge, потом приходи. Оно сейчас загнулось, но добрые люди выложили задания с решениями на гитхаб: https://github.com/agelastic/eudyptula

Тестовое задание: почини 12309.

А если серьезно, напиши мне в жаббер.

MPSSE

Реальная задача: FTDI умеет предоставлять далеко не только UART-интерфейс, но и, например, SPI и I2C благодаря MPSSE, но драйвер ядра умеет только UART, так что желающим использовать их приходится изголяться в юзерспейсе. Нужно прикрутить к драйверу ядра интерфейс SPI/I2C-хоста, дабы им могли пользоваться драйвера SPI/I2C-устройств уже существующие в ядре. Уже работающий в юзерспейсе код тут: https://github.com/l29ah/libmpsse/

Эта задача хороша тем, что у тебя скорее всего уже есть железо, а даже если и нет, оно стоит несколько баксов на али.

Вообще так многие работают. Маленькие частные задачи, старые архитектуры и платформы, все делают вполне индивидуальные разрабы. Да, корпорации могут оплачивать труд разработчиков 24/7 и соответственно кода от них больше, что логично. Так же корпорации часто поддерживают целые платформы. Но индивидуальный вклад никуда не делся. Бывают еще мелкие конторы из нескольких разработчиков, которые тянут вполне много кода. Тут больше зависит от качеств самих разработчиков.

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

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

• Отдебажь и исправь багу, которая лично тебе мешает жить
• Добавь драйвер для устройства, которое у тебя есть, но не поддерживается. Допустим, купил ты новую материнку, а на ней есть неподдерживаемый тип тепловых сенсоров, которые только в биосе и в винде считываются - отличный вариант
• Посмотри задания для программ типа GSoC, вполне возможно что есть куча невыполненных или зафейленных, у которых остались при этом заинтересованные менторы

Первое задание написать *strhr(*,*);! :D

А не получится ли так, что апстрим не примет этот код, так как задача решаема в юзерспейсе?

++i++

Я буду писать это когда будут спрашивать как у меня дела )))))))))

В юзерспейсе вообще всё решаемо, тем не менее ядро жиреет день ото дня.

Драйверы для всяких mtd-устройств в юзерспейс не вынесешь, например

Почему же?

Загружаться железке откуда-то надо

initramfs

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

Не помню чтобы я что-то говорил о долженствовании. Если нужно шоб очень всё быстро, то пихают в ядро, да. Не знаю поэтому ли, но примерно все драйвера для устройств SPI/I2C что можно встретить в GNU/Linux находятся в ядре, так что предложенный мной проект даёт вполне ощутимую пользу и вряд ли будет проигнорирован меинтейнерами. В конце концов, поддержку FTDI UART-то они впилили.

Ты можешь прикинуться геем и пойти в Outreachy.

А как файловые системы тогда работать должны, через fuse? это тупо медленно

Нууу, это спорно. У меня получалось 700-800 MB/s mixed read/write блоками по 128k, учитывая, что данные лежали на ext4 и весь индекс был в sqlite :)

Если нормально сделать FUSE (а у него есть довольно много архитектурных проблем, которые можно исправить другим дизайном), то потери можно ожидать порядка 10-15%.

Полоса пропускания разменивается на латенси, это не ново; в обратную сторону бы.

У Таненбаума, кажется, в «Сетях» есть момент, что скорость передачи информации в нашем мире ниразу не критична, это фундаментально; можно достичь сколь угодно большой. Критична латенси, ну и последовательные вычисления.

Ах, да, к чему это я. Даешь рандомные мелкие чтения через fuse! :)

Полоса пропускания разменивается на латенси, это не ново; в обратную сторону бы.

По latency не вспомню, но там не в разы разница была.

Ах, да, к чему это я. Даешь рандомные мелкие чтения через fuse! :)

Они в эту сторону двигались, насколько я помню. То есть это можно сделать, если убрать блокировки на пути и сделать per-cpu ring buffer с заданиями для приложения. А дальше ты биндишь треды своей файловой системы к очередям и попердолил. Накладные расходы на переключение контекста конечно выросли с приходом Meltdown, но это сейчас не самая критичная часть.

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

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

Возможно, мы про разного размера компании говорим. Большим копрорациям эти все плюсы от открытого когда менее важны.

per-cpu ring buffer с заданиями для приложения

интересно... А не будет ли этих буферов слишком много? А в каком месте они мержатся в реальные очереди к устройствам?

А дальше ты биндишь треды своей файловой системы к очередям

это кто делает? В рамках разработки FUSE драйвера или глубже уже в где-то в ядре?

В юзерспейсе вообще всё решаемо

Только вот никто не написал решения.

интересно... А не будет ли этих буферов слишком много? А в каком месте они мержатся в реальные очереди к устройствам?

Как в blk-mq. Пишется ядерная прослойка, которая создает массив из N per-cpu очередей. Когда приложение засылает реквест, прослойка кладет реквест в очередь (под nopreempt) и дергает твоей FS нотификатор. Твоя FS спрашивает через ioctl() список операций из конкретной очереди и обрабатывает их. Ну или через read(), не суть важно.

это кто делает? В рамках разработки FUSE драйвера или глубже уже в где-то в ядре?

В userspace :) Создаешь тред, который говорит ioctl'м «хочу, чтобы ты меня привязал к такой-то очереди». Ему возвращают eventfd от этой очереди, по которой же и аккаунтинг на выдачу данных делается.

Мы с чуваками такое для блочного драйвера в US делали, работало с очень небольшой добавленной латентностью. Порядка пары сотен микросекунд вроде. Я могу перепроверить попозже, у меня код остался :)

Басибо!

Я могу перепроверить попозже

не критично :)