Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Feb 27, 2021 4:25 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 41 posts ]  Go to page Previous 1 2 3 Next
Author Message
 Post subject:
PostPosted: Sat May 27, 2006 6:29 pm 
Serge
Я уже писал, что могу сделать поддержку директорий для рамдиска (для флопика ведь сделал) и описывал причины, по которым не сделал этого до сих пор. Это было в другой ветке форума.
Почему ты считаешь, что:
Quote:
Похоже, что путь "../data/my_save.dat" вызовет у файловой системы полуобморочное состояние.

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


Top
   
 Post subject:
PostPosted: Sat May 27, 2006 7:44 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
"..\" означает родительский каталог для текущего. Но в системе нет понятия текущего каталога. Я не могу вызвать для своей программы SetCurrentDir("d:\\os\\Kolibri\\programs\\my_program") и потом открывать файлы в этой папке просто open_file("my_file.1") open_file("my_file.2) или open_file("..\another_file.dat") для файла который находится в папке d:\os\Kolibri\programs. Система просто не поймет что значит "..\" потому что у нее нету понятия о текущих (рабочих) каталогах. А поддержка папок на рамдиске не самая актуальная проблема. Работа с каталогами на дисках намного важней. Думаю что стоит взять для примера файловые функции MS DOS, посмотреть как они работают и сделать свои аналоги. Этого хватило бы для нормальной работы файловой системы и для портирования C ( fopen, fread, fwrite, fseek).


Top
   
 Post subject:
PostPosted: Sun May 28, 2006 2:16 pm 
Serge
Я не очень люблю СИ. :-)
Но это ИМХО (поташнивает меня от него, несварение, однако).
А разве трудно сделать такую вещь как "..\" на уровне приложения? Код, который добавляет к названию файла еще и путь достаточно прост в моем понимании, а для ядра опять таки придется выделять область памяти, где будет, хранится этот путь, причем для каждого приложения своя область. Все реализуемо на уровне приложения, зачем нагружать ядро?
Не понимаю я этого удобства, наверное, это скорее сила привычки.


Top
   
 Post subject:
PostPosted: Sun May 28, 2006 5:01 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Это ведь не только C но и другие языки программирования. А относительные пути это ведь не прихоть MS DOS, всё идёт от UNIX и теперь во всех системах. Если этого не делать, то портировать код будет намного сложнее. Это пока программы достаточно простые и обходятся без своих каталогов. А попробуй представить здесь какой-нибудь майл-клиент или Firefox c кучей папок, пойдут проблемы. В общем получается спихивание проблемы на прнкладного программера. А они этого не любят :) и просто выбирают другие ОС.


Top
   
 Post subject:
PostPosted: Sun May 28, 2006 5:11 pm 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
Я тоже не очень люблю C,но приходиться на нем писать,так как не многие знают ассемблер.
Сейчас пишу на C одну программу.И всё больше понмаю,что по сравнению с ассемблером,C более ущемленный язык.То что на ассемблере делается легко,в C требует знания всяких библиотечных функций из-за которых алгоритм нагромождается и код разбухает.А вот математическая часть в C довольно прилично компилируется(если алгоритм короткий).Но с усложнение алгоритма,код становиться всёмене оптимальнее и начинает в разы и в десятки раз проигрывать ассемблеру.

Но без знания C невозможно портировать: Mesa(отрытая реализация библиотеки OpenGL),видео декодеры,интернет браузеры(пока нет ассемблерщика хорошо разбирающегося в сетевом программироании) и некоторые другие программы.
Знание C -это необходимость.


Top
   
 Post subject:
PostPosted: Sun May 28, 2006 8:39 pm 
Offline

Joined: Tue Apr 18, 2006 11:48 pm
Posts: 53
Mario79 wrote:
А разве трудно сделать такую вещь как "..\" на уровне приложения? Код, который добавляет к названию файла еще и путь достаточно прост в моем понимании, а для ядра опять таки придется выделять область памяти, где будет, хранится этот путь, причем для каждого приложения своя область. Все реализуемо на уровне приложения, зачем нагружать ядро?


А одновременный доступ к файлам тоже на уровне приложения делать? Вообще я тихо офигеваю от того, что приложение должно выделять буфер для работы файловой функции ОС.


Top
   
 Post subject:
PostPosted: Sun May 28, 2006 11:08 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
А чтение файлов фиксированными блоками?


Top
   
 Post subject:
PostPosted: Mon May 29, 2006 12:00 am 
Offline

Joined: Tue Apr 18, 2006 11:48 pm
Posts: 53
При чём здесь фиксированные блоки?


Top
   
 Post subject:
PostPosted: Mon May 29, 2006 12:36 am 
Offline
User avatar

Joined: Thu May 19, 2005 4:43 pm
Posts: 896
>При чём здесь фиксированные блоки?

Вот до чего доводит программирование на C.Люди начинают думать,что при чтении файла кэш память под блоки(файл ведь по блокам читается) не выделяется.А куда он по вашему должен деться ? :)
Для чего пишется
указатель=fopen("file.dat","r"); ?

В C эти проблемы берет на себя компилятор,а в ассемблере программист сам говорит сколько блоков(у каждого блока свой номер) и куда загружать.


>А одновременный доступ к файлам тоже на уровне приложения делать?

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


Top
   
 Post subject:
PostPosted: Mon May 29, 2006 2:20 am 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Quote:
Вот до чего доводит программирование на C.Люди начинают думать,что при чтении файла кэш память под блоки(файл ведь по блокам читается) не выделяется.А куда он по вашему должен деться ? Smile
Для чего пишется
указатель=fopen("file.dat","r"); ?
Файловый ввод/вывод в Си корнями уходит в Unix и работает не с собственно файлами, а с потоками в том числе stdin, stdout, stderr. Но вот прерывания ДОС позволяют читать/писать произвольное количество байт и с произвольной позиции так же как и ReadFile/WriteFile в WinAPI и без всяких блоков и вспомогательных буферов, поэтому я пользуюсь ими а не Си-шными fread/fwrite. Если мне надо считать из файла 20 байт по заданному адресу в структуру то мне не надо определять номер блока, считывать весь блок в специальный буфер и потом уже копировать необходимые данные. Все заботы по кешированию и буфированию берёт на себя система. А если использовать CreateFileMapping/MapViewOfFie то с файлом можно работать так, словно он весь уже загружен в память. Удобно однако :)


Top
   
 Post subject:
PostPosted: Mon May 29, 2006 8:55 am 
Offline

Joined: Tue Apr 18, 2006 11:48 pm
Posts: 53
andrew_programmer wrote:
Вот до чего доводит программирование на C.Люди начинают думать,что при чтении файла кэш память под блоки(файл ведь по блокам читается) не выделяется.А куда он по вашему должен деться ?


Вот кусок из инструкции:

======================================================================
========== Функция 58, подфункция 0 - прочитать файл/папку. ==========
======================================================================
Параметры:
* eax = 58
* ebx = указатель на информационную структуру
Формат информационной структуры:
* +0: dword: 0 = номер подфункции
* +4: dword: номер блока для чтения (считая с 0)
* +8: dword: число блоков для чтения
* +12 = +0xC: dword: указатель на буфер, куда будут записаны данные
* +16 = +0x10: dword: указатель на буфер для работы системы
(4096 байт)
* +20 = +0x14: ASCIIZ-имя файла, правила формирования имён указаны в
общем описании


Ну-ка расскажи, зачем тут нужен буфер по смещению 16? И каким образом чтение файла по блокам спасёт его от модификации другой программой?

andrew_programmer wrote:
>А одновременный доступ к файлам тоже на уровне приложения делать?
А это вообще забота операционной системы(точнее драйвера файловой системы).Програмист вызывает системную функцию чтения файла,а как организовать очередь доступа к файлу - это забота драйвера.


Так вот, выделением буферов под нужды операционной системы должна заниматся ОС, а не приложение.


Top
   
 Post subject:
PostPosted: Mon May 29, 2006 3:59 pm 
rabid rabbit wrote:
Ну-ка расскажи, зачем тут нужен буфер по смещению 16?

Для привидения имени файла в формат 8.3.


Top
   
 Post subject:
PostPosted: Mon May 29, 2006 4:53 pm 
Offline

Joined: Tue Apr 18, 2006 11:48 pm
Posts: 53
Ещё раз, почему выделением буфера под нужды ОС должно заниматься приложение?


Top
   
 Post subject:
PostPosted: Mon May 29, 2006 6:04 pm 
Serge
Прикладные программеры много чего не любят. :-)
Они вообще любят лепить код парой щелчков мыши, а то, что он будет занимать по 1-2 Мб на каждый щелчок мышки их как-то слабо интересует. В результате пользователь, тихо матерясь, и проклиная все на свете, покупает новый комп, потому что "Наш новый софт на новом железе работает быстрей, чем старый на старом".
Извиняюсь за флуд, но пробило, мочи нету.

Если ты считаешь что:
Quote:
Если мне надо считать из файла 20 байт по заданному адресу в структуру то мне не надо определять номер блока, считывать весь блок в специальный буфер и потом уже копировать необходимые данные. Все заботы по кешированию и буфированию берёт на себя система. А если использовать CreateFileMapping/MapViewOfFie то с файлом можно работать так, словно он весь уже загружен в память. Удобно, однако

То это можно со временем реализовать, не все сразу, однако. Проблемы мы решаем по мере поступления. Если оно не решалось раньше, значит, никто не ставил такой задачи и очень может быть, просто не было людей, который могли четко сформулировать конкретные вопросы. Ведь очень часто только и слышно "У вас нету, того и этого" при этом люди сыплют терминами мало распространенными и специфичными, даже не пытаясь объяснить суть. На вопросы что это такое обычно молчание с намеком, "Какие все тут ламеры", впрочем, речь не идет о постоянных посетителях форума.

rabid rabbit
Quote:
А одновременный доступ к файлам тоже на уровне приложения делать? Вообще я тихо офигеваю от того, что приложение должно выделять буфер для работы файловой функции ОС.

Я конечно отмазываюсь, но:
1) Это разработано еще Великом - большим специалистом по написанию ОС (он уже 4-ю ОС пишет, насколько я понимаю).
2) Что офигительного в выделении буфера в области приложения? Приложение что жаба задушит?
Ядро все равно с одинаково скоростью организует доступ, что к памяти, отведенной под себя, что к памяти отведенной к приложению.
Конкретно выделив место под буфер, нет нужды занимать стек, то есть, он лишний раз не распухнет, и не дойдет критического значения, то есть не пересечет выделенную для него область.
Теперь приведи свои доводы против такой реализации (не считая эмоций) и того, что так не привычно, я с удовольствием выслушаю и возможно мы изменим ситуацию.


Top
   
 Post subject:
PostPosted: Mon May 29, 2006 7:51 pm 
Offline
Kernel Developer

Joined: Wed Mar 08, 2006 6:25 pm
Posts: 3952
Mario79
Конечно файловые сервисы одни из самых сложных в любой ОС и за два дня их не напишешь. Я это прекрасно понимаю. Но всё же, думаю стоит взять за основу хотя бы функции MS DOS. Можно конечно идти своим особым путём но тогда не стоит ждать, что будет большое количество желающих написать что-то для Колибри.
Что касается места под буфер то скорее всего нужен один буфер на все приложения. А если каждая программа будет выделять свой собственный буфер, то будет впустую расходоваться память. Еще один аргумент. Файловые сервисы могут выполняться не в контексте вызвавшей задачи, а отдельным потоком в адресном пр-ве ядра. Такая схема сложнее но надёжней потому что только один сервис будет иметь доступ к диску и можно избежать ситуаций когда одна программа начала считывать файл, прервалась на середине и другая файл переписала.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 41 posts ]  Go to page Previous 1 2 3 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited