LINUX.ORG.RU

[COOL KERNEL HACKERS WANTED][FEATURE REQUEST] Реализация revoke (2) в Linux ядре

 


0

0

Я уверен, тысячи людей во всём мире будут вам благодарны, если вы напишите вызов revoke (2) для ядра Linux'a. Сразу скажу - дело не простое, и почитайте для начала http://lkml.org/lkml/2009/6/1/395

Если у вас есть желание написать «оно не надо», пожалуйста, промолчите, я вас умоляю.

P.S. Почти все BSD имеют этот вызов, в WinNT он реализован чуть ли не с 1993 года. Зачем оно? http://bugzilla.kernel.org/show_bug.cgi?id=14505

Всем заранее спасибо.

★★★★★

Долго возиться а потом в конце пути встретить стену непонимания при попытке замержить в апстрим? Ну его нафик такое счастье.. :-/

PS: Нет, долгий тред в LKM не читал. Но IMHO вполне реализуемо в постановке 'поубивать всех нафик на заданной точке монтирования'.

bibi
()

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

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

Deleted
()

birdie ***** (*) (16.11.2009 18:57:59)

Иногда они возвращаются...!!!

golodranez ★★★★
()
Ответ на: комментарий от nikolayd

The revoke (); system call invalidates all current open file descriptors in the system for the file named by Fa path . Subsequent operations on any such descriptors fail, with the exceptions that a read (); from a character device file which has been revoked returns a count of zero (end of file), and a close (); system call will succeed. If the file is a special file for a device which is open, the device close function is called as if all open references to the file had been closed.

Ну в такой постановке конечно муторнее. Там ещё начнутся сумасшедшие пляски с пространствами имен (вызов по пути) и пр. радости. В общем, ковырять линуксовый VFS - занятие не для слабонервных :)

bibi
()
Ответ на: комментарий от xydo

>всё уже написано
по крайней мере umount, который может убивать все файловые дескрипторы в пределах точки монтирования в природе существует

xydo ★★
()
Ответ на: комментарий от xydo

по остальным пунктам:
>1) In a multiuser environment you may not want to close applications running under a different user account - you want to keep them running.

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

>2) Finding such applications should not be a concern for a root user (yes, I known about fuser).

увы, должен именно он. конфликты между пользователями решаются админом.

xydo ★★
()
Ответ на: комментарий от xydo

> всё уже написано.

хотя не факт, что ты найдешь патчи.

Рабочих патчей нет, почему их не приняли в ядро - таки почитайте дискуссию на LKML.

Линуксовый VFS - это не сказка, а ещё есть ... /dev/lo[0-9]+ :)

Работа, я так понимаю, требуется колоссальная ... или VFS в Линуксе спроектировано через одно место. ;)

anonymous
()
Ответ на: комментарий от xydo

fuser убивает процессы - иногда это крайне не хочется.

e.g.

10 # cd /media/flash
20 # run_something
30 # run_something_else
40 # logout

теперь попробуйте umount /media/flash, не убивая 20 и 30. А ведь там могут быть запущены процессы, которым _вообще_ точка монтирования не нужна, а они её держат, ибо оттуда запущены.

ну разве не sucks? ;)

anonymous
()
Ответ на: комментарий от xydo

> по крайней мере umount, который может убивать все файловые дескрипторы в пределах точки монтирования в природе существует

увы, только в вашем воображении:

man umount:

-l Lazy unmount. Detach the filesystem from the filesystem hierarchy now, and cleanup all references to the filesystem as soon as
it is not busy anymore. (Requires kernel 2.4.11 or later.)

-f не смотрите, оно только для NFS.

anonymous
()
Ответ на: комментарий от anonymous

>увы, только в вашем воображении:
то, что ты не знаешь о его существовании еще не значит, что его не существует :)

xydo ★★
()
Ответ на: комментарий от xydo

> то, что ты не знаешь о его существовании еще не значит, что его не существует :)

хороший юмор не повредит? :)

anonymous
()
Ответ на: комментарий от anonymous

А вроде было что-то типа umount --force?

mono ★★★★★
()
Ответ на: комментарий от anonymous

"процессы, которым _вообще_ точка монтирования не нужна" и при этом длительные по времени должны запускаться из другой текущей директории или сами менять свой текущий каталог на что-нибудь неубиваемое. (я, например, так поступал при разработке одного эпликэйшена, даже несммотря на то, что у меня была возможность прибить дискриптор).
принцип такой: если прога ничего не делает с текущим каталогом, то и нефиг ей в нём сидеть.

>Работа, я так понимаю, требуется колоссальная

правильно понимаешь.
причем затраты на нее не окупаются в принципе: profit не особо-то и большой от этого.

xydo ★★
()
Ответ на: комментарий от anonymous

>хороший юмор не повредит? :)
конечно не повредит. чем не поржать над очередным ограниченным аноном с ЧСВ over 9k.

xydo ★★
()

>в WinNT он реализован чуть ли не с 1993 года

Как интересно... А почему, когда требутеся отмонтировать флешку, начинается траходром типа "найди, кто занял девайс"?

Macil ★★★★★
()
Ответ на: комментарий от anonymous

> А ведь там могут быть запущены процессы, которым _вообще_ точка монтирования не нужна, а они её держат, ибо оттуда запущены.

Ну так думать надо, когда процессы запускаешь.

LamerOk ★★★★★
()
Ответ на: комментарий от Macil

> начинается траходром типа "найди, кто занял девайс"?

google: procexp

:)

anonymous
()
Ответ на: комментарий от Macil

>Как интересно... А почему, когда требутеся отмонтировать флешку, начинается траходром типа "найди, кто занял девайс"?
Нуууу этооооо так сказать... вон! там! птичка!(быстро убегает)

особенно интересно, если команда dd получила доступ к файлу /dev/sda, сильно ли ей помешает исчезновение этого файла внезапно

dimon555 ★★★★★
()
Ответ на: комментарий от dimon555

особенно интересно, если команда dd получила доступ к файлу /dev/sda, сильно ли ей помешает исчезновение этого файла внезапно

А ей то что? Ну вернут ей EIO на очередную операцию. Ну ругнется она, выдаст сообщение юзеру да выйдет. Не вижу проблемы.

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

bibi
()
Ответ на: комментарий от dimon555

>особенно интересно, если команда dd получила доступ к файлу /dev/sda

Вообще-то /dev/sda "исчезнет", только в случае отмонтирования /dev. Ну, или физического удаления девайса.

Macil ★★★★★
()
Ответ на: комментарий от Macil

Вообще-то /dev/sda «исчезнет», только в случае отмонтирования /dev. Ну, или физического удаления девайса.

Вставили флешку - ядро подхватило девайс. Вынули - удалило. Причем ему пофигу - примонтированов устройство или нет. Нет флешки - нет девайса. Это как пример.

bibi
()
Ответ на: комментарий от bibi

>Вставили флешку - ядро подхватило девайс. Вынули - удалило.

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

lester_dev ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.