Date: Tue, 12 Sep 1995 13:55:26 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: current@freebsd.org Subject: Re: userconfig doesn't work on tvi925 Message-ID: <199509122055.NAA02265@phaeton.artisoft.com> In-Reply-To: <199509121213.OAA29278@uriah.heep.sax.de> from "J Wunsch" at Sep 12, 95 02:13:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I don't see the harm in making 'userconfig' a USERCONFIG kernel option, > > however. In fact, it originally started out being an option, but everyone > > seemed to agree that it was too useful to ever be without...so we made it > > standard. > > This reminds me: is there any chance to get parts of the kernel > pageable? > > (My current understanding is that a.out lacks the ability to carry > additional sections that would be required for this.) I think it's worse than that. One would expect that to be pageable, one would have to set the page descriptor explicitly, probably via #pragma when generating the code segements in the first place. This is what MSVC2.x does for VXD's in Win95. The programmer would then be responsible for not making as pageable any code that could execute from interrupt mode. One of the consequences of this (though it's not obvious) is that the spl/splx that allows malloc/free at interrupt level would need to go away. Pretty much, it's an abomination before God in any case. This implies an ability to schedule tasks to occur in regular processing once interrupt mode is exited. Basically, bifurcating the drivers into ISR's and soft handlers. This is both good and bad. It's good because it would make much of the kernel pageable. It's bad because of the GCC and ld hacks needed, and the restrictions that it imposes on usable driver architectures. For instance, writing a file system under Win95, you need to lock down many (most) of the pages for the FSD (File System Driver) because the plug-n-play manager can call back into routines at interrupt level, or at the very least, with paging disabled. It does this to support paging from the device itself (meaning anything in the page-in/page-out path must be locked down) and to support device change notifications so that a file system can act properly when a removable media is about to be ejected (a design flaw in the pnp module, IMO). One potential "benefit" would be the potential to, at some future date, support the use of VXD's, though this would require a kernel environment emulation several orders of magnitude more complex than that needed to support using, for instance, NetWare, UnixWare, Solaris, or SCO drivers. A better use of effort (again, IMO) would be to support the SCO, Solaris, and NetWare drivers, and if you get overambitious, NT (not Win95). Good luck decoding OMF. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509122055.NAA02265>