Re: [RFC] Virtual 8086 mode su pport for kernel drivers

Jan Klötzke <[email protected]> wrote:
> > I was actually thinking of just reusing the thread::fault_handler 
> > field.
> > Its use is currently only defined for page faults in kernel mode, 
> > so there
> > wouldn't be any collisions (it is nesting anyway, since one is 
> > usually
> > required to reset it to its previous value). One could also use a
> > (nameless) union to avoid casting.
> I also understood your proposal that way. But as a generic facility 
> it could 
> be used by other drivers as well (even though I have no other usecase 
> yet ;-) ). If a driver/module registers a page_fault_callback for 
> longer 
> times (e.g. across syscalls) and a unhandled page fault happes in the 
> kernel 
> then the page_fault_callback address would be used in the old 
> fault_handler 
> address sense and would not lead to a panic. Therefore I chose to 
> make it 
> explicit...

I don't really see any usage case for this, though - and even if there 
is one, the current fault handler mechanism should be sufficient IMO.

> > BTW, I believe it is preferrable to add only *.cpp files in the 
> > kernel. We
> > have a few headers that are quite messy, since they actually use C+
> > +
> > features, but are included by *.c files. We are (very slowly) 
> > renaming *.c
> > files to *.cpp, and I was hoping we would be able to clean up the 
> > headers
> > one day.
> Ok. Then maybe it's also an option to merge the struct vm86_state and 
> the vm_* 
> functions into a class? What's the direction Haiku is heading in this 
> respect?

In the kernel itself, you can do what you prefer - the only rule is 
that we currently only export C API.

Bye,
   Axel.


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Open-beos-kernel-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/open-beos-kernel-devel