ioctl внутри ядра

Смотреть, что вызывает нужный тебе ioctl. ioctl использует copy_from_user()/copy_to_user() для работы с параметрами, которые просто откажутся копировать из/в пространство ядра.

c copy_from_user проблем нет

  mm_segment_t fs = get_fs();

  set_fs(get_ds());
  control = filp_open("/dev/mapper/control", 0, 2);
  if (IS_ERR(control)) {
    DMINFO("Unable to open /dev/mapper/control");
    goto outfs; }

  // тут подготавливаем структуру dmi... для запроса

  error = control->f_op->ioctl(control->f_path.dentry->d_inode, control, DM_DEV_CREATE,(unsigned long)dmi);
  if(error<0) { DMERR("DM ioctl %d.\n", error); goto outfree; }

  // поскипано

outclose:
  filp_close(control, current->files);
outfs:
  set_fs(fs);

Под убунтой все прекрасно работает, устройство DM создается и проблем нет. Но как только я пытаюсь это дело запустить на target машине control->f_op->ioctl=NULL
я не пойму, какие опции ядра еще необходимо указать чтобы это все работало. :(

CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set

Вроде бы этого должно быть достаточно чтобы был доступен интерфейс dm-ioctl.

> c copy_from_user проблем нет

Ну да, addr_limit у кернельного процесса такие штуки позволяет сделать.

> Вроде бы этого должно быть достаточно чтобы был доступен интерфейс dm-ioctl.

Судя по Kconfig и Makefile - да, должно хватать. А как f_op в остальном вообще выглядит на target-машине?

Спасибо. нашел ошибку -- в данном случае, поскольку я не использую CONFIG_COMPAT, dm устанавливал f_op->ioctl в NULL, f_op->compat_ioctl в NULL, а вот f_op->unlocked_ioctl указывает на правильную функцию.

Все заработало :)