The real one question, to find answer to, was: use PXE in protected mode (which is hazy documented in Intel specs and PXE SDK), or do everything in real mode, except memory copy routines, which start protected mode and end it after copy operation (this case is good, but limits usage of commonly used fuctions, that I wanted to use from libstand).
Now I am thinking, the best way – to use BTX and virtual 86 mode or do something similar on basis of BTX v86 monitor and protect mode initialisation.
So, here again to ways:
1. implement “disk via http” for loader (as PXE here: libi386/pxe.c ) and use tcp lib for that.
2. make independent solution based on tcp lib and initialisation code similar to BTX, but it needs more reading, how kernel loads if no drive is specified.
common in this two cases is – tcp lib, so I’ll start from this. Then best choice to do code in common way “disk via http”, that will test main tcp lib code work and usability. And then will be time to think about independent solution, which requires more information about kernel arguments and more understanding of bootinfo struct usage.
Although libstand will be used, calls to it functions (memory allocation, timer, console out) will be through wrappers with `pxe_` prefix. That will be useful, if somewhere in future I’ll decide not use libstand, also it may be more flexible for porting or code usage in other OS, which have no libstand.
Well, libi386/pxe.c already uses such prefix (pxe_open(), pxe_enable() and etc), but I think usage will be different and there would not any naming problems. For “drive over http” will be used `pxe_http_` prefix.
I think first recieve/send buffers will be static to avoid dynamic allocation. In case of this project it’s possible, cause pxe_http code must handle practically one connection most of time.
Hm, today I’ll try to include pxe_http dummy support to loader and look how it works. After success I’ll sync some files via perforce. And we’ll see if I understand tuning p4 client correctly.