CGI интерфейс и консольный ввод/вывод.

Mon Feb 04, 2013 5:45 pm

http://wiki.kolibrios.org/wiki/%D0%9A%D ... libriOS/ru
Я не ведущий разработчик, но не против иметь стандартные средства для stdin/stdout, а не эмулируемые в клиентском приложении. Однако, реализация должна быть "прозрачной" для желающих использовать стандартные потоки.

Mon Feb 04, 2013 5:57 pm

SoUrcerer wrote:Однако, реализация должна быть "прозрачной" для желающих использовать стандартные потоки.

Я этого не понял...

Mon Feb 04, 2013 6:05 pm

Не должно быть много "магического" кода. Инициализация и работа с потоками должна быть логичной и простой.

Mon Feb 04, 2013 6:11 pm

Ну, потоков это совершенно не касается. Реализация будет на уровень процессов - в рамках одного процесса, будет только одного набора консольных сокетов. Потоки будут создаваться и пользоваться как всегда.

Mon Feb 04, 2013 7:23 pm

Я имею в виду потоки ввода-вывода - stdin, stdout

Mon Feb 04, 2013 8:45 pm

Теперь понял. Работа с ввод/выводом будет весьма простая - через fn.75.6 (SocketSend) и через fn.75.7 (SockerReceive). Номера сокетов будут находится в заголовке приложения:
Новый заголовок будет вот такой:

Code: Select all

      db 'MENUET01'
      dd $02                 ; New header version
      dd START
      dd I_END
      dd RESERVED
      dd STACK_PTR
pArg  dd 0
pPath dd 0
      ; IO socket numbers.
STDIO dd 0
ERRIO dd 0

Приложение будет запускаться через ф.70.7, а в файловой информационной структурой будут использоваться поля на смещения 12 и 16, которые теперь не используются.
То есть, структура будет:

Code: Select all

struct __TFileOp7
  .subfunc     dd 7
  .flags       dd ?    ; 1 = start in debug mode
  .pArguments  dd ?
  .hSTDIO      dd ?     ; now it is reserved/not used
  .hSTDERR     dd ?     ; now it is reserved/not used
               db 0
  .pFileName   dd 0     ; pointer to the filename
ends

Mon Feb 04, 2013 11:07 pm

А hidnplayr, придумал даже вариант проще - использовать последние две dword вот так:

Code: Select all

      db 'MENUET01'
      dd $01
      dd START
      dd I_END
      dd RESERVED
      dd STACK_PTR
STDIO  dd ptrArgBuffer
STDERR dd ptrPathName

Эти поля не используются после загрузки приложения, потому что программа и так знает где находятся эти адреса.
Поэтому все старые программы должны работать.

Tue Feb 05, 2013 12:09 am

Не понял со вторым случаем. Как тогда можно понять, что программе кроме параметров передают что-то через stdin?

Tue Feb 05, 2013 1:06 am

Параметры и вовсе не передаются через stdin. Ядро копирует эти параметры в буфере на ptrArgBuffer. Этот указатель нужен ядру только во время загрузки программы, а она и так знает где этот буфер находится. Поэтому, эта переменная не используется в программе. И поэтому, когда ядро скопирует параметры, то на самом месте, можно записать номер сокета для STDIN/OUT
То же самое относится и для ptrPathName.
А если процесс, который загружает программу не использует этот механизм (например старые программы), то в эти переменные загружаться нули. (это и единственный риск - если программа ожидает что там будут валидные адреса, а вдруг там появятся нули. Но вероятность для этого мала).

Tue Feb 05, 2013 10:29 am

I will continue this discussion in English.

It seems we didn't guess one important issue, about the second approach. The dynamic libraries could use the fields pArg and pPath, because they can't know where these buffers are placed.

Tue Feb 05, 2013 5:18 pm

I dont know of any library currently using those parameters, if they are needed the program can pass the path and arguments buffers easily.
There is also the option of using some of the other available bytes/dwords.

Tue Feb 05, 2013 6:17 pm

(+) So, no compatibility will be broken.
(-) But, some (hypothetical) features will be lost.
(+) A new ~~entities~~ header will not be introduced.

So, the balance is positive... I'll make it this way.

BTW: How I should work on this task? I already checked out the kernel sources and I probably must work on network branch... Or maybe I have to fork another branch...
Should I send a patches to someone or the workflow is different...
Sorry, but I have experience only with DVCS, where these things are more liberal.

Tue Feb 05, 2013 7:16 pm

johnfound wrote: BTW: How I should work on this task? I already checked out the kernel sources and I probably must work on network branch... Or maybe I have to fork another branch...
Should I send a patches to someone or the workflow is different...
Sorry, but I have experience only with DVCS, where these things are more liberal.

Applying the proposed patch to network branch makes sense to me.
You just need write access to SVN and then you theroretically can do what you want

Tue Feb 05, 2013 8:25 pm

I have added the socketpair function to the net kernel.
The code however is untested because I dont feel like writing the application for it right now.

I am however, pretty confident that nothing will explode.

Sun Feb 10, 2013 12:00 am

I didn't understand about compability with old programs. May be it is advisable to use some magic constant.

Code: Select all

      db 'MENUET01'
      dd $02                 ; New header version
      dd START
      dd I_END
      dd RESERVED
      dd STACK_PTR
pArg  dd 0
pPath dd 0
  MAGIC dd 0x12345; <---- Some magic constant
      ; IO socket numbers.
STDIO dd 0
ERRIO dd 0

CGI интерфейс и консольный ввод/вывод.

Who is online