From owner-freebsd-mobile Wed Nov 5 17:28:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA25957 for mobile-outgoing; Wed, 5 Nov 1997 17:28:16 -0800 (PST) (envelope-from owner-freebsd-mobile) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA25945 for ; Wed, 5 Nov 1997 17:28:09 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word.smith.net.au (localhost.gsoft.com.au [127.0.0.1]) by word.smith.net.au (8.8.7/8.8.5) with ESMTP id LAA00464; Thu, 6 Nov 1997 11:51:12 +1030 (CST) Message-Id: <199711060121.LAA00464@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Poul-Henning Kamp cc: Mike Smith , Nate Williams , freebsd-mobile@freebsd.org Subject: Re: Libretto 50 - US Version and PAO In-reply-to: Your message of "Wed, 05 Nov 1997 15:29:03 BST." <1014.878740143@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 06 Nov 1997 11:51:11 +1030 From: Mike Smith Sender: owner-freebsd-mobile@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >No, we're out. If we want to be able to run Linux WABI, it wants > >(AFAIR) everything from 11 or 12 and up. At any rate, I think I have a > >solution which deposes the APM descriptors and makes them "general > >purpose" ones. I'll know Friday when I get to test it. > > they What ??? > > They must be out of their mind :-( Quite possibly. Willows TWIN wants (by default) everything from 12 up. At least we have source for that. Check with sos about WABI; he was closer to having it run than I was. > >> I do not like the > >> idea of trying to go through the vm86 interface to get to the APM. > > > >I was only *ever* proposing this for dealing with APM biossen that > >don't support the 32-bit interface. I don't actually know if it's > >worth the effort though, as we don't support such systems now... > > Ahh, ok. Oh, and doing the connects, for obvious reasons. > >Hmm, I should get you to add my extra PnP rummaging and see which event > >signalling mechanism it uses. In particular, I'm interested to know if > >anyone uses the 'system device' method rather than the 'polled flag' > >method. > > polled flag in my case. Thought so. The 'system device' method would involve about 10x as much code I think. > >I have an interface (the PnP protected-mode interface, FWIW) which > >expects to be called via a "far call", ie. lcall seg:ofs. It also > >wants to take arguments on the (16-bit) stack. I'm trying to work out > >how to write an assembly shim to make this possible, as gcc doesn't > >grok "far" in any way shape or form. > > > >Presuming I have the segments created correctly, how do I make a call > >into another segment with arbitrary arguments on the stack? (I need to > >arrange a new data segment as well...) I'm stuffed on this one, short > >of custom-rolling a shim for each argument arrangement... > > I looked at that one. My idea was to do two levels of wrappers: Yeah, these are the ideas I had. I wanted implementation suggestions 8) > 1. (Inline) Assembly > call_pnp(segment, offset, int stackdepth, u_int16_t *stack) You left the data segment out... One thing I was wondering; does pnp_func(u_int16_t a, u_int16_b) construct the stack properly, or will we still get int-sized objects on the stack? mike