гугл и сей гайд, но вопросов больше чем ответов.)
Дано:
Дровина. В ней обработчик ioctl. В нём мы
1. читаем что прислал юзер через copy_from_user
2. В зависимости от cmd и присланных данных делаем что он просит. (в основоном это либо pci_read/write_config либо readl/writel
3. Пихаемся в него ответом через copy_to_user
Вопрос в том, что у меня в начала этих мероприятий стоит spin_lock, в конце spin_unlock, оно врооде как бы работает, но гугл говорит. что лочить спин на столь длинное время - идея, конечно, забавная, но может иметь неожиданные последствия в виде полного зависания компа при удачном стечении обстоятельств.
В качестве решения, как я понял, предлагается mutex_lock/unlock но я не могу вкурить что и как лочить, с учётом того, что так же в кернел-хакинге говорится, что Avoid holding spinlock for more than 5 lines of code and across any function call (except accessors like readb()). (то есть, как я понял, функции доступа аля readb нужно лочить спинлоком)
Собственно, непонятно, что из этого выбрать:
1. Заменить spin_lock на spin_lock_irqsave и так же лочить всю функцию.
2. Лочить мьютексы на copy_from/to_user, а доступ к регистрам или read/writeb лочить спинлоком (Или spin_lock_irqsave)
3. Лочить всю функцию мьютексом.
4. Иное?
Лочить только куски, читающте/пишущие глобальный state. То есть хочешь измегить какую-нибудь скорость — лочишь структуру со скоростью в памяти, меняешь, меняешь регистр в девайсе, разлочиваешь.
Если реально девайс по миллисекунде реагирует — устраивай очереди или выкидывай лишних писателей.
Товарищи, а как правильно опакететь `.ko-`шку в дебиано-подобных дистрах? Просто идея "зашвырнуть .ko-шатину в /usr/lib/modules/$(uname -r)/ мне кажется мягко говоря, странной.
dkms mkdeb / dkms mkbmdeb
и вот так просто при наличии только Makefile и .c-шных сорсов должен появиться пакет?
Я вот что не понял - а если я нехороший человек и не хочу шарить сорсы - это тоже работает?
Обсуждают сегодня