Date: Fri, 1 Aug 2003 16:20:05 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: deischen@freebsd.org Cc: Marcel Moolenaar <marcel@xcllnt.net> Subject: Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...) Message-ID: <Pine.BSF.4.21.0308011619000.46065-100000@InterJet.elischer.org> In-Reply-To: <Pine.GSO.4.10.10308011911520.321-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 1 Aug 2003, Daniel Eischen wrote: > On Fri, 1 Aug 2003, Marcel Moolenaar wrote: > > > On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote: > > > > > > LUCODE_SEL is used by kernel to load _ucodesel to user %cs > > > > LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs. > > > > I didn't check other ABIs, but setting to a fixed location of LDT in userland > > > > is also a bad idea, I think it will conflict with thread library soon, > > > > it is better to use dynamic allocating facility newly added in i386_set_ldt. > > > > > > 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). > > I can see the need to keep the old behavoir for compatibility's > sake. How about we complain loudly on the console when it's done.. (for the first few times) (with info on how to do it right) > > -- > Dan Eischen > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0308011619000.46065-100000>