Системный вызов.

> При входе в обработчик системного вызова

в зависимости от того, что под этим понимается.

но sys_whatever() вызывается с irq enabled.

тот что нрописан в соответсвующем поле fops

хотел бы я знать, что бы это значило.

По первому спасибо.

По второму, имел ввиду функции адреса которых сохранены в struct file_operations переданной в cdev_init(). (Если по русски то реализация действий драйвера в ответ на sys_whatever()) Сказал криво, согласен.

>По второму, имел ввиду функции адреса которых сохранены в struct file_operations переданной в cdev_init(). (Если по русски то реализация действий драйвера в ответ на sys_whatever()) Сказал криво, согласен.

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

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

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

spinlock в прерывании - убийство!
лучше уж пусть флаг реализует, а в нижней половине обрабатывает уже со всякими спинлоками...

> spinlock в прерывании - убийство!

а чё делать, если надо?

в нижней половине обрабатывает уже со всякими спинлоками...

вообще говоря, bh - это тот же irq context.

>spinlock в прерывании - убийство!

Ну, не обязательно. Может там клавиатура или еще какое игрушечное устройство.

К тому же это выбор автора - из irq handler ковырять соответствующие данные. Про всякие cpu-bound очереди и тому подобное он, наверняка, знает, но просто не везде они нужны.

Вот именно spin_lock_irq/save/() и хочу вставить именно для критических участков а не на весь обработчик. Понятно что в обработчике прерывания должно быть irqsave, хотел для себя подтвердить что в системном вызове можно юзать irq.

Почему убийство?

> spinlock в прерывании - убийство!

Это почему?

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

Начинать смотреть нужно отсюда:

set_system_trap_gate(SYSCALL_VECTOR, &system_call);

эта... я педант и зануда, но тогда уж нужно смотреть
wrmsrl(MSR_LSTAR, system_call) или wrmsr(MSR_IA32_SYSENTER_EIP)

set_system_trap_gate(SYSCALL_VECTOR) - это только для 32bit
и даже там устарело.

Может и протухло. Зато наглядно.

да я ж не спорю. просто дополнил чуть-чуть.