RE: [line-devel] RE: Interrupt vector

[Michael S. <ms...@ac...>]

[...]
>> The 3 major
>> reasons
>> I dont really work on line is that
>> 1) I get really frustrated using GDB/emacs under cygwin.
>> 2) I really dont know enough about linux
>What is the third ??

Oops
	I really dont have the time


>> 1) make interrupt 80 reflect through an LPC port to a ring 3 process
>> 2) implement the linux APIs in the ring3 process
>> 3) move that implementation to the ring 0 interrupt handler.

>Hmm...Michael. Can I ask you to spend a few time and make everything for
me?

>You propose to create something like Win32 sybsystem does in NT3.51 ?
>I.e. create native NT app which will create new native NT thread for each
>Linux
>process and make fast context swaps using int 80/8x ?
>What does 3) mean ? Are syscalls will be processed in ring3 or ring0
>(i.e. are Win32 API will be called in ring0 (????) or ring3 or no Win32
will
>be used) ?

Not exactly.
step 2)
	a) when an int 80 gets called, the interrupt handler makes a call to an LPC
port.
	b) that gets handled by a single threaded process running in ring 3. This
process
	will use the Native API to implement the syscall.  The process context swap
gets
	handled by the LPC port.
in step 3)
	remove the LPC call and move the code that handles the syscall into the
device driver.

In step 2, syscalls are processed in ring 3, in step 3 syscalls are
processed in ring 0.

in step 3 there is no process context swap.

an implementation that stops at step 2 will be slow, but relatively easally
developed.

it's been a while, but i checked in come code in
<lineroot>/un/hookint/hookint.c that
uses LPC to pass the interupt registers up to ring 3 and back out again.

At the point that I stopped developing,  I also had code that basically
created a native
process and emptied all the mapped dlls that I could from it.  the next step
would
have been to look at the linux current_process structure (I think thats what
it is)
and build an equivilent to map into that process space (or ring 0 space).
Then create an executable memory segment in that process space that does an
exec of bash.

much easier said than done.

>Do you propose create own sybsystem and call NT microkernel directly or
>we will create Win32 service which will only extend Win32 sybsystem API
>(preffered for fast development speed, but not for fast execution) ??

eventually it would get rid of win32 entirely. build the service under win32
so
you can use the debugger, but implement the syscalls using the native api.
I'm not sure about your definition of microkernel.  If it means
"anything that runs under ring 0" then yes.  if it means "only the HAL" then
no.


>Sorry for a lame questions, there is a lot of ways to implement that we
need
>and
>it's not clear from your e-mail how you propose to do this.

They're not lame questions,  It's lame of me to pontificate on how to do
things without a) knowing much about linux and b) having much intention
of actually doing it.
	Mike

P.S.  I have seen threads about the intrinsic differences between
linux/posix
mmap and NT memory management.  does it just have to do with the allocation
granularity?

=============================
Andrew G. Tereschenko
Software Engineer
Integrated Banking Information Systems
ta...@ib...



_______________________________________________
line-devel mailing list
lin...@li...
http://lists.sourceforge.net/lists/listinfo/line-devel