Загрузка библиотек

Internal structure and you change requests/suggestions
  • Честно говоря, несмотря на то, что я за то, чтобы максимально высвободить ядро от функций, которые оно делать не должно, но эта функция представляется мне как раз той, что действительно необходима в ядре.

    Впрочем, я и сейчас не вижу особых проблем.
    К примеру, вот пару дней назад я переписал вызов fontslib с использования loadlib.mac на dll.inc, синтаксис работы с библиотеками в котором мне нравится больше. Сделал быстро и код вполне читабелен:

    Code: Select all

    START:
    	mcall	68,11
    	stdcall dll.Load,@IMPORT
    	or	eax,eax
    	jnz	exit
    	; Инциализация библиотеки fontslib
    	invoke fonts.init	; инициализация списка шрифтов 
    	invoke fonts.get_font
    
    ...
    
    @IMPORT:
    library \
    	fontslib,'fonts_lib.obj'
    
    import fontslib, \
    	fonts.init				,'initialization_font',\
    	fonts.get_font			,'get_font',\
    	fonts.free_fulder_info	,'free_fulder_info',\
    	fonts.free_font			,'free_font',\
    	fonts.draw_string		,'font_draw_on_string',\
    	fonts.show_all			,'show_all_glif',\
    	fonts.version			,'version_fn'
    
    Готово, все нужные функции доступны через invoke.
    Last edited by maximYCH on Mon Aug 15, 2011 8:39 am, edited 2 times in total.
  • maximYCH wrote:Честно говоря, несмотря на то, что я за то, чтобы максимально высвободить ядро от функций, которые оно делать не должно, но эта функция представляется мне как раз той, что действительно необходима в ядре.
    Я тоже за "облегчение" ядра посредством переноса всех левыхъ функций В библиотеки и именно поэтому предложил эту идею.
    Также использование макросов/велосипедного кода имеет минус для небольших, крошечных программ, имхо. Ибо код загружающий библиотеку в них может занимать места больше, чем основной код программы. С использованием же системного вызова он будет занимать 8-15 байт.
  • Загрузчику, как и "тяжёлым" драйверам (вроде файловых систем) в ядре делать нечего: они его прилично раздувают и усложняют, а выигрыша в плане скорости такое решение практически не даёт (в связи с медленной работой "по определению" этих компонентов: оно настолько превосходит время переключения контекста, что им можно смело пренебречь). Целесообразнее их делать в виде задач режима пользователя, общающихся с ядром через стандартизированный интерфейс. Помимо всего прочего, это прилично облегчит написание и отладку таких компонентов, а также обеспечит лёгкость их расширения. Наконец, поведение ядра, и, в частности, время его работы станет предсказуемее (время работы загрузчика или какого-нибудь тяжёлого драйвера предсказать вообще невозможно, поскольку оно зависит от внешних факторов, например, расположения файлов на диске). В случае с загрузчиком его вынос из ядра позволяет легко обеспечить загрузку и COFF, и ELF, и ещё каких-нибудь форматов, какие кому-то понадобятся, без каких-либо изменений в ядре. Другое дело, что надо проектировать, а потом реализовывать этот самый стандартный интерфейс, а также функции управления памятью (загрузчик-то должен иметь доступ к адресному пространству чужой задачи), да и вообще сначала думать, а потом писать... :)
  • Ну ничто не мешает сделать такую функцию для загрузки только COFF-библиотек (как стандартных и нативных для Колибри), а поддержку других исполняемых/линкуемых форматов переложить на загрузчики для user mode.
  • Выносить код загрузки библиотек из приложений, разумеется, нужно, но не в ядро, а в системную user-mode библиотеку, которая будет грузиться автоматически, получать управление до основного приложения и всё настраивать. Например, это позволяет без проблем вызывать функции инициализации в библиотеках - которые, естественно, должны выполняться в user-mode - и существенно разгружает ядро от деталей, которые там не нужны.

    Длинный флейм по вопросам формата и загрузки динамических библиотек был на форуме здесь и здесь. В конечном счёте вроде активные на тот момент ядерщики согласились на формат PE с урезанным заголовком, но, как это часто бывает с флеймами, всё загнулось.
    Сделаем мир лучше!
  • Если вытащить загрузку программ/библиотек из нулевого кольца, то можно будет вовсе отказаться от идеи "Каждой ОС свои форматы экзешников и либ". Программист будет выбирать тот формат, который ему по душе и/или с которым он лучше_знаком/привык_работать.
  • Точнее, с которым умеет работать его любимый компилятор.
  • Загрузка из user-mode создаёт некоторые проблемы с расшареными библиотеками.
  • Joaquin: много форматов, тоже не очень хорошо.
  • Serge wrote:Загрузка из user-mode создаёт некоторые проблемы с расшареными библиотеками.
    Собственно, нужно нормальное управление памятью, и в частности, её совместным использованием несколькими задачами. Если такового нет, то реализовать загрузчик в режиме пользователя не получится (ну, не считая включения его кода в каждую задачу -- пускай и в виде системной библиотеки, автоматически загружаемой ядром при запуске задачи).
  • :?

    Это просто общая шиза какая-то: выносить из ядра всё, что работает...
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • art_zh, в данном случае проблема в том, что сейчас загрузка библиотек не работает. По крайней мере, нормально. По причинам, которые изложил Joaquin в первом же посте этой темы.
    SII, я, конечно, понимаю, что вам лишь бы поругать отсутствие проектирования и документации на внутреннее устройство ядра где-либо, кроме мозгов разработчиков, и что вам безразлично, что на самом деле уже есть, но для вновь прибывших я считаю своим долгом сообщить о существовании расшаренной памяти на уровне API - функции 68.22 и 68.23. К которым нет принципиальных проблем прикрутить примочки типа copy-on-write. Если, конечно, не считать того, что делать это некому, но указанная проблема не является специфичной для обсуждаемой темы.
    Сделаем мир лучше!
  • art_zh wrote::?

    Это просто общая шиза какая-то: выносить из ядра всё, что работает...
    Кстати о "выносить из ядра всё, что работает"... Это только мне одному кажется, что LZMA-распакеру в ядре делать нечего?
  • Ядро же запакованное, как оно само себя распаковывать будет?
  • Who is online

    Users browsing this forum: No registered users and 4 guests