Board.KolibriOS.org
http://board.kolibrios.org/

Вопрос по пути ;)
http://board.kolibrios.org/viewtopic.php?f=2&t=522		 Page 3 of 3
Author:  rabid rabbit [ Mon May 29, 2006 9:45 pm ]
Post subject: 
Mario79 wrote:
Я конечно отмазываюсь, но:
1) Это разработано еще Великом - большим специалистом по написанию ОС (он уже 4-ю ОС пишет, насколько я понимаю).
2) Что офигительного в выделении буфера в области приложения? Приложение что жаба задушит?
Ядро все равно с одинаково скоростью организует доступ, что к памяти, отведенной под себя, что к памяти отведенной к приложению.
Конкретно выделив место под буфер, нет нужды занимать стек, то есть, он лишний раз не распухнет, и не дойдет критического значения, то есть не пересечет выделенную для него область.
Теперь приведи свои доводы против такой реализации (не считая эмоций) и того, что так не привычно, я с удовольствием выслушаю и возможно мы изменим ситуацию.


Тут Serge уже выступил, но и у меня есть, что добавить ;) Вот сейчас в документации прописан размер этого буфера в 4К. В следующем релизе ядра этого оказывается недостаточно. Соответственно, старые проги идут лесом ;) Если уж так повелось переложить задачу выделения этого несчастного буфера на приложение, можно предусмотреть вызов, который скажет приложению, какого размера буфер выделить. Так, например, построены многие вызовы в нелюбимой здесь винде ;)
Кстати, если ядро может выделять память только в стеке, значит у него отсутствует возможность динамически выделять себе память. Уууу, как всё запущено ;)
Author:  halyavin [ Tue May 30, 2006 7:25 am ]
Post subject: 
Serge
Если одна программа начала считывать файл, прервалась на середине, а другая файл переписала, то это проблема пользователя, который одновременно читает и пишет в один и тот же файл из разных программ. Если одна программа заняла файл и ты теперь не имеешь к нему доступа вообще, то это тоже не сладко.
Вообще, для разруливания таких ситуаций придуманы объекты синхронизации, которые с успехом там и используются.
Author:  diamond [ Tue May 30, 2006 10:09 am ]
Post subject: 
В новой 70-й функции буфер не нужен. И данные она измеряет не в блоках, а в байтах.
Author:  Mario79 [ Tue May 30, 2006 6:00 pm ]
Post subject: 
Serge
Quote:
Файловые сервисы могут выполняться не в контексте вызвавшей задачи, а отдельным потоком в адресном пр-ве ядра. Такая схема сложнее но надёжней потому что только один сервис будет иметь доступ к диску и можно избежать ситуаций когда одна программа начала считывать файл, прервалась на середине и другая файл переписала.

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

rabid rabbit
Quote:
Вот сейчас в документации прописан размер этого буфера в 4К. В следующем релизе ядра этого оказывается недостаточно. Соответственно, старые проги идут лесом

Кто тебе сказал такое?
Я уже писал - буфер используется лишь для хранения и преобразования пути, и размеры я уже описывал.

Quote:
Так, например, построены многие вызовы в нелюбимой здесь винде

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

Quote:
Кстати, если ядро может выделять память только в стеке, значит, у него отсутствует возможность динамически выделять себе память. Уууу, как всё запущено

Я не говорил, что оно не может этого делать. Я лишь привел пример одной из возможных реализаций.

И вообще давай займись исправлением некоторых вещей, раз ты в них хорошо понимаешь. Это будет гораздо эффективней простой критики на форуме. От этого все только выиграют.

diamond
Зато нужен стек. Но я не говорю что это не хорошо. Главное, что работает и работает хорошо.
Author:  rabid rabbit [ Tue May 30, 2006 6:54 pm ]
Post subject: 
Mario79 wrote:
Кто тебе сказал такое?
Я уже писал - буфер используется лишь для хранения и преобразования пути, и размеры я уже описывал.


Ты точно уверен, что ничего не поменяется? ;)


Quote:
Я не говорил, что оно не может этого делать. Я лишь привел пример одной из возможных реализаций.


Обычно то, что приводят в пример, является единственным возможным вариантом ;)

Quote:
И вообще давай займись исправлением некоторых вещей, раз ты в них хорошо понимаешь. Это будет гораздо эффективней простой критики на форуме. От этого все только выиграют.


Здесь нечего переделывать, нужно всё придумывать с нуля.
Author:  halyavin [ Tue May 30, 2006 9:03 pm ]
Post subject: 
О! Вступай в общество разработчиков дисковой драйверной подсистемы. Вторым будешь. Может хоть что-нибудь начнем делать.
Author:  rabid rabbit [ Tue May 30, 2006 10:00 pm ]
Post subject: 
Я не против :)
Author:  diamond [ Tue Jun 20, 2006 5:15 pm ]
Post subject: 
halyavin, rabid rabbit И как продвигается?
Теперь по пунктам рассмотрим все обвинения.
Quote:
Похоже, что путь "../data/my_save.dat" вызовет у файловой системы полуобморочное состояние.

Могу совершенно точно сказать, что будет в текущей реализации 70-й функции. Вернётся (сразу же) значение 5, file not found. Система действительно не поддерживает понятия текущей папки, но :!: добавить такую поддержку не слишком сложно - ориентировочно порядка сотни-двух строчек на всё про всё (фактически нужно всего лишь хранить идентификатор текущей папки, для FAT достаточно 4-байтового кластера + код для SetCurrentDirectory + проверка в начале 70-й функции). Так как, уже надо?
Quote:
Вообще я тихо офигеваю от того, что приложение должно выделять буфер для работы файловой функции ОС.

70-я функция не нуждается в разворачивании имени в 8+3, а потому и буфер для такого разворачивания не нужен. (В файловой структуре даже поля такого нет).
Quote:
А чтение файлов фиксированными блоками?

Для 70-й функции нужно указывать смещение и размер в байтах.
Quote:
Если мне надо считать из файла 20 байт по заданному адресу в структуру то мне не надо определять номер блока, считывать весь блок в специальный буфер и потом уже копировать необходимые данные. Все заботы по кешированию и буфированию берёт на себя система

Уже.
Quote:
А если использовать CreateFileMapping/MapViewOfFie то с файлом можно работать так, словно он весь уже загружен в память. Удобно однако

Чего нет, того нет (пока?) А это очень нужно? Ведь фактически всё равно потребуется выделить память и прочитать файл в эту память. Так что никакого выигрыша в производительности не будет.
Quote:
ситуаций когда одна программа начала считывать файл, прервалась на середине и другая файл переписала

Работу ядра с диском прервать нельзя (если произошло переключение задач и новая задача запросила что-то с диска, то она подождёт, пока не закончит старая программа). Ну а если приложение обращается к ядру порциями, то, как справедливо заметил halyavin,
Quote:
Если одна программа начала считывать файл, прервалась на середине, а другая файл переписала, то это проблема пользователя, который одновременно читает и пишет в один и тот же файл из разных программ. Если одна программа заняла файл и ты теперь не имеешь к нему доступа вообще, то это тоже не сладко.
Вообще, для разруливания таких ситуаций придуманы объекты синхронизации, которые с успехом там и используются.
Author:  vectoroc [ Tue Jun 20, 2006 6:39 pm ]
Post subject: 
а совместный доступ быть не может? вроде как открытие только для чтения в нескольких прогах...
Author:  Mario79 [ Tue Jun 20, 2006 7:06 pm ]
Post subject: 
Victor
В текущей реализации совместного доступа нету. Поскольку все потоки равноправны, то любой поток (включая поток ядра) ждет, пока поток начавший дисковую операцию не завершит эту операцию. Одновременно можно обращаться только к разным физическим устройствам, но даже в этом случае нельзя, например, обращаться сразу к 2-м флопикам, потому что контроллер, который их обслуживает, содержится на системной плате в единственном экземпляре. И еще нельзя обращаться одновременно к Master или Slave устройствам по одному и тому же контроллеру, потому что опять таки контроллер один на 2 устройства. Распараллеливание доступа к одному и тому же устройству конечно можно реализовать, но не так скоро. Такую систему надо продумывать. К тому же в PIO режиме ее однозначно не имеет смысла делать вообще, так что сначала надо реализовать режим DMA для винта и сидюка.
Author:  diamond [ Tue Jun 20, 2006 7:14 pm ]
Post subject: 
Тем не менее это всё в ядре; если приложения читают файл небольшими блоками (а хоть бы даже и большими) - без проблем два приложения могут псевдопараллельно читать один файл. (Примерно по той же схеме, что один процессор исполняет кучу программ).
Page 3 of 3 All times are UTC+03:00
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/