Date: Fri, 1 Aug 2003 19:57:12 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: current@freebsd.org Subject: Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...) Message-ID: <Pine.GSO.4.10.10308011947500.6535-100000@pcnet5.pcnet.com> In-Reply-To: <20030801233758.GA7023@dhcp01.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Aug 2003, Marcel Moolenaar wrote: > On Fri, Aug 01, 2003 at 07:18:11PM -0400, Daniel Eischen wrote: > > On Fri, 1 Aug 2003, Marcel Moolenaar wrote: > > > > > On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote: > > > > > > > Perhaps we need to rethink the interface and disallow > > > > specification of any ldt; only allow dynamic. We would > > > > need a different method of setting an array of them, though. > > > > > > Why not allow setting a specific entry when it's currently unused > > > and not reserved by us? > > > We can simply fail if the process is trying to set a LDT entry that's > > > currently being used or is reserved by us. The only case that causes > > > problems is when an existing LDT entry is overwritten by another > > > consumer. > > > > That's what I was worried about. Once an application or > > library is written to use specific LDTs, you never know > > how it will be affected by the use of threading libraries > > (or other libraries using threads). > > But if we only use the dynamic allocation then it can only fail for > a combination of 3rd party code. It should always work when there's > just one 3rd party piece of code involved. This makes it work for > anything we should care about. The moment a process is constructed > with various 3rd party pieces compatibility is out of our hands > anyway (compatibility between the various 3rd party pieces that is). If your 3rd party code is a library, and other application code is built to be threaded (or use other libraries that are threaded) _and_ use this 3rd party library, then you have a problem. You don't know what ldt allocation is going to come first. If our dynamic allocations are made first and the 3rd party static allocations are made next, then you can have something whacky ensue. It may not even be the same all the time; it could depend on which button a user clicks first. OpenGL is the example that I was thinking about. > Having a way to disallow using the static allocation should be easy > if we use compiler magic to test that the LDT entry is constant and > 0. If it is, all is ok (assuming that I'm not mistaken that we use a > 0 entry to indicate dynamic allocation -- I haven't actually paid > that close attention to it). If the LDT entry is non-constant, it > can still be 0 of course but I expect that to be a weird border case. This is all good :-) -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10308011947500.6535-100000>