Зарезервированные слова в SysFn09 (информация о потоке )

Internal structure and you change requests/suggestions
  • Serge wrote:Если не исправили, значит устраивает.
    Вот! Зерно истины!
    Serge wrote:Когда я активно занимался ядром то наводил порядок в данных, сколько мог. Ты и сам это знаешь. Но работа эта нудная и неблагодарная, заниматься ей сейчас я не могу, а других желающих не видно.
    Да, я знаю потому не стал тыкать пальцем, о чем в предыдущем посте и сказал. Дело не в желающих, а в назревшей необходимости. У кого во что упирается и ограничивается, тот тем и занимается. Наведение порядка исключительно ради наведения порядка - на это мало кто решается. Да, собственно ты сам обозначил "Если не исправили, значит устраивает." - добавлю значит не мешает жить и работать. Когда-нибудь, кто-нибудь - допилит, если будет необходимость.
  • Nasarus wrote:Не совсем понял, как таким образом можно избежать правок существующих программ.. :?:
    У 9-й функции очень кривой вызов, даже подфункцию не воткнешь.
    Но расширенный системный сервис все-таки можно реализовать, если использовать для этого саму структуру.
    В новых программах при 9-м вызове можно где-нибудь записать какую-нибудь характерную сигнатуру (например db 'Nasarus',0 )
    - тогда ядро будет знать, что нужно будет заполнять структуру после 75-го байта, и еще места хватит для размера "хвоста", номера подфункции и чего еще душа пожелает.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • art_zh, теперь понял, спасибо что объяснил ;)
    ушёл...
  • Лучше новый вызов сделать, так надёжнее. И для него разработать новый формат структуры.
  • Serge, +5. Нужно заранее продумать структуру, чтобы информация об окне шла в одном диапазоне, PID/TID собсвтенный/родителя/дочерних потоков в другом диапазоне, остальная информация тоже должна быть разложена "по полочкам". Во-вторых, надо вместо строк (имя файла, например) ложить в буфер указатели на них.
    ушёл...
  • У меня возникла аналогичная мысль. Приведу её в относительно развёрнутом виде.

    A. Проект плана действий

    (1) До следующей стабильной версии создаём новую функцию, позволяющую получить всю информацию, которую пока можно получить только посредством SysFn09. Эта функция уже
    - должна быть в духе KolibriOS,
    - не содержать недостатков SysFn09.
    (см. ниже в Б.)
    (2) В следующей стабильной версии KolibriOS:
    - SysFn09 объявляем как Deprecated;
    - в качестве приоритетного TODO устанавливаем замену вызовов SysFn09 на вызовы новой функции во всех приложениях.
    - в качестве среднесрочного TODO устанавливается размещение всех структур ядра KolibriOS так, чтобы отдельные записи не пересекали страничных барьеров несмежных страниц в физической памяти (или что-то в таком духе: см п. (3) )
    (3) Когда предыдущий этап будет полностью завершён (прогнозирую, что это будет реально через 2 - 3 года)
    - SysFn09 становится недоступной для обычных приложений (которые, естественно, не имеют никакого доступа к адресному пространству ядра): возвращает код ошибки;
    - для привилегированных приложений, которые имеют доступ к адресному пространству ядра в режиме "только для чтения", SysFn09 (а): возвращала (в eax) код ошибки/успеха + (в ebx) адрес соответствующей структуры ядра (на всякий случай дополню - в адресном пространстве вызывающего привилегированного процесса/потока) + (в ecx) размер соответствующей области данных или что-то в таком же духе; (b): имела подфункции - по одной для каждой структуры ядра KolibriOS.

    Б. Проект интерфейса функции - замены SysFn09

    Параметры для всех подфункций:
    eax = номер функции
    ebx = номер подфункции
    ecx = номер слота потока (ecx = -1 - получить информацию о текущем потоке)
    edx = размер буфера (*если требуется: если данные не умещаются - в буфер помещаются только начальный фрагмент)
    esi = указатель на буфер (*если требуется)

    Возвращаемые значения:

    Для всех подфункций:
    eax - код успешности операции (-1 - некорректные параметры(остальные регистры неизменны); 1 - слот не занят(остальные регистры неизменны); 0 - успешное выполнение операции(регистры содержат корректные данные))

    Для подфункции 0 (основная информация об окне потока)
    ebx = координата окна потока по оси x
    ecx = координата окна потока по оси y
    edx = размер окна потока по оси x
    esi = размер окна потока по оси y


    Для подфункции 1 (основная информация о клиентской области)
    ebx = координата начала клиентской области по оси x
    ecx = координата начала клиентской области по оси y
    edx = ширина клиентской области
    esi = высота клиентской области

    Для подфункции 2 (дополнительная информация об окне и оконном стеке)
    ebx = позиция окна потока в оконном стэке
    ecx (точнее - bl)= состояние окна - битовое поле (бит 0 (маска 1): окно максимизировано ;бит 1 (маска 2): окно минимизировано в панель задач ; бит 2 (маска 4): окно свёрнуто в заголовок )
    edx = (не имеет отношения к запрошенному потоку) номер слота потока, окно которого находится в оконном стэке в позиции ecx [примечание: честно говоря, я не понимаю смысла этого текста - просто скопировал пояснение из документации SysFn09]
    esi = (не имеет отношения к запрошенному потоку) максимальный номер слота потока

    Для подфункции 3 (основная информация о потоке)
    ebx (точнее - al)= состояние слота потока:
    0 = поток выполняется
    1 = поток приостановлен
    2 = поток приостановлен в момент ожидания события
    3 = поток завершается в результате вызова функции -1 или насильственно как следствие вызова подфункции 2 функции 18 или завершения работы системы
    4 = поток завершается в результате исключения
    5 = поток ожидает события
    ecx = идентификатор (PID/TID)
    edx = битовая маска событий данного потока (в соответствии с описанием SysFn40)
    esi = использование процессора (сколько тактов в секунду уходит на исполнение именно этого потока)

    Для подфункции 4 (основная информация о процессе:* требует указания буфера для имени процесса)
    буфер данных = имя процесса
    ebx = адрес процесса в памяти
    ecx = размер используемой памяти - 1
  • Firewall, отличная идея. Зачастую процессу нужно узнать всего лишь один параметр (PID, например) и ради него приходится выделять целый килобайт памяти. Да и скорость работы таких программ как CPU, @panel должна, по идее, увеличится в разы, а код упростится.
    ушёл...
  • Nasarus! Спасибо за поддержку!

    Пока выжду 10 дней:
    - это позволит мне привести в порядок результаты "второго тренировочного заезда" (см. соседнюю ветку данного форума);
    - это позволит собрать критические замечания по поводу проекта интерфейса функции - альтернативы SysFn09;
    - это позволит перехватить "право реализации" этой функции тому, кто сможет сделать предварительную рабочую версию этой функции за один вечер.
  • Есть одно пожелание - чтобы в подфункции 0 были самые важные данные о процессе (имя, PID/TID)
    ушёл...
  • То есть Вы предлагаете что-то вроде:

    Для подфункции 0 (основная информация о процессе:* требует указания буфера для имени процесса)
    буфер данных = имя процесса
    ebx = адрес процесса в памяти
    ecx = размер используемой памяти - 1
    edx = PID/TID потока (в последующем PID процесса)

    Для подфункции 1 (основная информация о потоке)
    ebx (точнее - al)= состояние слота потока:
    ...
    eсx = битовая маска событий данного потока (в соответствии с описанием SysFn40)
    edx = идентификатор (PID/TID)
    esi = использование процессора (сколько тактов в секунду уходит на исполнение именно этого потока)

    А остальные функции далее ...

    P.S.

    Кому что кажется более важным :)
  • Да, примерно так я и предлагал ;)
    P.S. Ну, как минимум, идентификатор - самая важная информация о процессе.
    ушёл...
  • ebx = адрес процесса в памяти
    Если это базовый адрес процесса, то он 0 для всех. Значение имело смысл до перехода к страничной памяти.
  • Тогда его надо чем-то заменить осмысленным, например,
    - адресом директории страниц процесса (это в прицеле на будуще: привилегированный процесс может иметь желание читать данные из адресного пространства других процессов);
    - физическим адресом первой страницы процесса;
    ...

    (И соответственно определнить понятие "базовый адрес процесса")

    Другой вариант - убрать из новой функции
  • Цитата: "Ну, как минимум, идентификатор - самая важная информация о процессе."

    Если Вы имеете в виду PID/TID, то это пока имено TID - идентификатор потока. Насколько я понимаю, пока в KolibriOS идентификатора процесса нет. (Поэтому я пока и продублировал возврат этого значения в двух подфункциях.)
  • Who is online

    Users browsing this forum: No registered users and 5 guests