Alexey Tarasov’s notes

Now, path to the result becomes cleaner, but harder

The main thing to do now – install interrupt handler for NIC. Implemented by BTX vm86 monitor reflects interrupts to vm86 task. So user client application (BTX client) must find which interrupt number is needed (PXE API provides such information), and install handler for it in which call pxe_core_isr().

Installation phase is sophisticated, cause we need to change IDT and client code is executed not in ring 0 as I understand. So, there is SYS_EXEC system call (__exec() ), but according to assembler code there must not be return from code, run by this call, otherwise SYS_EXIT executed. In my case I only need to install handler, and that’s all. If I use __exec(), after IDT modification the only process flow is exit() , or stay forever in ring 0, while PXE related code will be running. The last case is not what I want, cause idea is to save as much boot functionality as possible (and thus to return control to BTX client code).

So, what I need to correctly install interrupt handler? That is the question. If I understand correctly – the one way is to modify btx.S and add another syscall, that allows to install interrupt handler (something like super2user_isr_install(), that installs handler, which calls user defined function in user space.).

Well, there is also another way – use reflected interrupts, and add handler (modify interrupt vector table) in vm86 space. In that case there must be some call to notify user code (not in vm86, but in ring 3) that interrupt occured. That is also needs system call (something like real2user() and user2real() . vm86int() does sequentially pseudocode user2real(), real_call(), real2user(), but it’s needed to be possible to make this code backwards).

I guess, if somebody ever needed installing interrupt handler in BTX client. If I’m understanding all correctly, then first variant with super2user_isr_install() seems better solution than second one.

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.

Well, I’ve just created this blog and will try to drop here some lines every few days. Mainly, here’ll be my thoughts about tcp implementation in preboot environment and some notes about current state of project.
Now it’s a plenty of time before deadline, so I’m reading documentation and getting along with Perforce. I am looking now to syslinux implementation of some PXE functions and Intel PXE 2.1 specification.

Also, it seems good idea to use libstand (or parts of it) for common functions, so I’m digging what is possible with it.