Трудно понять, насколько конкретно написано задание, а сколько оставлено «для творчества». Я бы предположил из упомянутого, что через /proc должны передаваться имена файлов для обработки.

Как создавать и/или читать файлы из kernel space? Хотел бы я на это посмотреть.

Ну тут если с именами файлов еще более менее понятно, их-то я получил, остаются 2 проблемы:

1) Как открыть и считать файл внутри модуля, имея только его имя ( в гугле нашел пару упоминаний о том, что так делать ни в коем случае нельзя, вроде как из lkm рассылки, и какое-то одно странное решение)

2) В какой момент производить чтение и запись, то что я выше описал про «чтоб склеить файлы мне нужно вызывать «cat /dev/test1»?»

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

в российскую компанию в питере устраиваешься что ли?

я такое дикое задание от одной видел. практически 1-в-1.

вообще читать системным вызовом в ведре можно. главная проблема в том, что будет ругаться uaccess на ядерные адреса. тебе надо заглушить ругать uaccess на адрес в ядре.

гугли uaccess kernel space address

либо ты можешь покопаться в нутре ядра и посмотреть кого вызывает sys_open.

Ну я так подозреваю что компания та же, но не в Питере. Я вообще не знаю что делать, мне закинули задание и не отвечают, я уже третьи сутки спать нормально не могу

http://lxr.free-electrons.com/ident?i=filp_open

Там же есть примеры использования.

То есть я правильно понимаю, что это не я что упускаю, а задание странноватое и придется все-таки вкручивать костыли?

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

Должен быть голый модуль, или допускается вспомогательная программа? Иначе дичь какая-то.

Если я все правильно понял, то: extern struct file *filp_open(const char *, int, umode_t);

«const char *» - сюда просто вбить имя файла? Что-то вроде:

filp_open(«/tmp/test1», 80, MODE)

Обязательно попробую чуть позже, спасибо

Вот тут не знаю, это все что есть. Я написал разве что init скрипт, чтоб автоматически создавать девайс по номеру из /proc/devices. Вот думаю туда же впилить еще и имена файлов, итого получится шелл скрипт с 4 параметрами( start|stop + файлы ). Звучит так себе, но других вариантов я не вижу

Я не эксперт, так, слышал кое-что :). Фактически любые файловые операции из юзерспейс все равно выполняются ядром. Другое дело, что для юзерспейс программ ядро неявно выполняет некоторые другие операции, потому корректный код для для копирования одного файла в другой в ядерном модуле будет более многострочным, чем в обычной программе.

ну как тут выше написали, открыть/закрыть файл ты можешь с filp_open/filp_close. читать/писать - вот это делают

// Get current segment descriptor
fs = get_fs();
// Set segment descriptor associated to kernel space
set_fs(get_ds());
// Read the file
f->f_op->read(f, buf, 128, &f->f_pos);
// Restore segment descriptor
set_fs(fs);

это собственно обман uaccess который проверяет, чтоб userspace адрес из ядра не подсунул.

Так вот что это такое, я видел этот код, но не особо понял зачем он нужен. После словесного описания все встало на свои места, большое спасибо.

это собственно обман uaccess который проверяет, чтоб userspace адрес из ядра не подсунул

Это законно? Так можно делать или это из под вывиха? Может ТС-а проверяют на аккуратность следования канонам и правилам, его склонность поддаваться на соблазн костылевания... :)

Ну а куда деваться? Сам ответа не нашел, спросил там где его могли бы знать если бы он был. Не сказать же мне «Не по канонам, отказываюсь такое писать!». Задачу нужно решить, какая бы странная она ни была, ну а если вариантов действительно нет - то почему бы и не вкрутить костыль

К тому же еще непосредственное слияние строк я буду выполнять через 'cat /dev/test1'. Как по мне - это максимально странный вариант, но надо же как-то дернуть этот девайс, других вариантов я особо не вижу.

бро, помоему от тебя не хотят cat. помоему от тебя хотят чтоб ты у файлов узнавал через poll когда можно читать.

Это не в NatSys Lab тестовое задание?

The most common question asked in this don't-do-that category is, “How do I read a file from within my kernel module?”

http://www.linuxjournal.com/article/8110

Вот это кстати интересная идея. Я конечно понятия не имею что такое poll, но догадываюсь. Можно еще шедулер какой прикрутить, и вообще огонь будет. Спасибо за идею

сомневаюсь

2) Мы можем читать/писать файлы в /proc

Похоже, лучше через sysfs:

http://www.linuxjournal.com/article/8110

Кстати, интересно, тот кто дал задание, заходит на ЛОР?

Ну если через /proc, то самое простое будет

cat file1.txt >/proc/my_driver_proc_entry
cat file2.txt >/proc/my_driver_proc_entry
cat /proc/my_driver_proc_entry > file3.txt

Как делать proc entry смотреть здесь: http://www.makelinux.net/ldd3/chp-4-sect-3

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

Идеально, я просто счастлив :3

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

нет понимания как это склеить по-человечески

В таком решении требуется буфер в памяти, уж не знаю какой там можно динамический придумать, cat будет тебе выдавать череду записей блоков по 32 Кбайт (например). Если файлы будут по 5 гигабайт, то не знаю что будет.

В таком решении требуется буфер в памяти

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

Если файлы будут по 5 гигабайт, то не знаю что будет.

Ничего не будет если в proc_write сделать проверку на остаток места в буфере и возвращать ошибку

Вообще /proc насколько я знаю в основном используется для проверки статуса или конфигурирования, что подразумевает сравнительно небольшие объемы данных. Можно конечно представить что кто-то реально льет гигабайты на/c железа через /proc, но что-то мне подсказывает что для этого существуют более подходящие методы

ну ходит и что. лучше спросить у людей совета, чем самому херачить вслепую