Как из блочного устройства сделать обычный файл?

Если речь идёт о драйвере, может проще экспортировать содержимое в виде файла в sysfs? Хотя всё это ужасные костыли и надо чинить программу

пиши в tmpfs, оттуда копируй нормальным cat/dd на устройство

ну так внятно и напиши, что за программа, и почему именно «отказывается». какая ошибка?

Что за программа, каким образом отказывается? Кто автор программы? Кто автор драйвера устройства?

Согласен, программа кривая. Но исходников нет, к сожалению.

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

В принципе, вариант, если при загрузке читать из устройства в tmpfs и потом в цикле писать обратно. Но как-то тоже костыльненько.

Программа проприетарная. Почему она отказывается, я не знаю. Можно было бы strace на неё натравить, но пока не успел. Пишет ошибку, мол, не могу ни прочитать ни записать. Но если подсунуть ей обычный файл, то всё прекрасно пишет и читает.

Автор драйвер устройства — Andrew Lunn. Драйвер из дерева ядра.

Возможно она пытается узнать размер через stat() и фейлится на этом. Но это не точно :)

А losetup вы уже пробовали?

Не пробовал, но мне кажется, что результат будет похожим, так как losetup тоже создаёт блочное устройство. Стоит попробовать?

Что-то же нужно делать. Начинать с этого. Что-то типа

losetup —-show -f file.img

ln -s blabla /dev/blabla не работает? Я далеко от ПК, не могу сейчас проверить.

Попробую. Хотя тоже есть сомнения. Пробовал так, кстати:

mount --bind /dev/mtdblock0 file

file, естественно, тоже видится в системе блочным устройством и прога его тоже не воспринимает.

Не понятно как это будет использоваться, зачем это «блочное устройство энергонезависимой памяти крохотного объёма»?

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

Я впервые узнал о losetup от тебя, но если теоретизировать, ничто не мешает ему скормить девайс вместо образа (всё есть файл же) и обычный путь к файлу вместо пути к девайсу.

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

В этой памяти хранятся всякие настройки, часто изменяемые значения, которые должны переживать перезагрузку. Они не могут находиться во флеш-памяти, так как могут перезаписываться по 100 раз в секунду.

По хорошему надо бы strace-ом пройтись, ну просто хотя бы оценить объем проблемы, а так можно бесконечно тыкать.

программа может не работать с устройством из-за прав доступа

Не, она от рута запускается.

Поэтому хотя бы strace нужен. Там и вправду могут быть права доступа на какой-нибудь mmap.

Пишешь в read-only, например

Не, с этим тоже всё в порядке, легко могу писать и читать из устройства.

Я всё ещё не понимаю твоей аппаратной ситуации.

Что мешает программе работать с обычным файлов хоть на диске, хоть на РАМДИСКЕ. Чтобы этот файл пережил перезагрузку копировать его на блочное устройство поблочно без ФС (dd)

Товарищ конечно тот еще партизанин, но по-видимому он хочет поставить и забыть, а так придется вручную копии делать или автомат какой-то колхозить.

Я впервые узнал о losetup от тебя, но если теоретизировать, ничто не мешает ему скормить девайс вместо образа (всё есть файл же) и обычный путь к файлу вместо пути к девайсу.

Нет, losetup создаёт именно устройство. Даже если ты как-то заставишь его создать dev-файл вне его штатного пути в /dev/, он всё равно останется файлом блочного устройства. Устройство вместо файла подать на вход может быть и можно, но пользы автору от этого не будет.

Нагуглил решение через FUSE: https://superuser.com/questions/1845620/how-can-i-access-a-block-device-file-as-a-regular-file-with-defined-size-in-linu

Да, так можно сделать, я не против, но чтобы данные не пропали их придётся переносить «вручную» из устройства в файл и обратно. Не совсем удобно.

О, круто! Что-то интересное. Спасибо!

а где гарантия, что прога закончила писать и данные консистентны?

Raw-device хочешь ты. Которое /dev/raw

Возможно не очень :)

raw is used to bind a Linux raw character device to a block device.

Хороший вопрос, кстати! Если делать свой велосипед, то придётся как-то реализовывать атомарность записи. В каком формате прога пишет данные — неизвестно, в каком-то своём проприетарном, видимо. Возможно, что эта атомарность уже в ней реализована и если я полезу туда со своими костылями, то только напортачу.

Да, из блочного делает символьное.

С блочным устройством ты вынужден работать с выравнивание 512 байт. С символьным это ограничение снимается. Поэтому делай как тебе подсказано - натягивай символьный raw поверх блочного и потом это символьное отдавай приложению.

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

Поглядел strace-ом вызовы. После успешного открытия файла (или устройства), программа вызывает ftruncte() и если успех, то вызывает mmap() на этот файл. То есть ни блочное, ни символьное устройства не подходят, также не подходят ни ссылки на ни, ни бинд-маунты. Только обычные файлы, к сожалению. Даже когда монтирую через свой FUSE-драйвер с опцией direct_io, то тоже не проканывает, из-за того, что mmap() не дружит с direct_io, насколько я понял.

Ну вот! А мы тут копья бьем.

Ладно, друзья, всем спасибо за дельные советы!

Сделал через FUSE в итоге. Кривенько-косенько, но как-то работает. Посмотрим как поведёт себя в продакшене xD

Вот все у нас так, кривенько-косенько. Потом возмущаемся про engineering debt.

:)

конкретнее, а как именно?

Примерно так:

static struct fuse_operations retain_operations = {
    .getattr    = my_getattr,
    .readdir    = my_readdir,
    .open       = my_open,
    .release    = my_release,
    .read       = my_read,
    .write      = my_write,
    .truncate   = my_truncate,
    .fsync      = my_fsync,
};

С реализацией указанных функций, для работы с блочным устройством. Например:

static int my_readdir(const char *path, void *buf, fuse_fill_dir_t filler,
                         off_t offset, struct fuse_file_info *fi)
{
    (void) offset;
    (void) fi;
    
    if (strcmp(path, "/") != 0)
        return -ENOENT;
    
    filler(buf, ".", NULL, 0);
    filler(buf, "..", NULL, 0);
    filler(buf, "myfile" + 1, NULL, 0);
    
    return 0;
}

После монтирования (./myfuse /path/to/mountpoint) появляется myfile, на который я и натравливаю программу.

можно просто назвать очередной упоротый небоскрёб из костылей «абстракцией», «парадигмой» «бест практисес» или «так нагляднее и читаемее» и всё вмиг станет по феншую