From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 15 Jun 2009 23:00:46 -0700 Message-ID: Subject: Re: [9fans] interface for per process gdt manipulation From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Topicbox-Message-UUID: 0b7a034e-ead5-11e9-9d60-3106f5b1d025 On Mon, Jun 15, 2009 at 10:37 PM, wrote: >> i haven't looked at your code, >> but a text interface is better than binary. >> if you make the first field the table index number, >> then you don't need to bother with seeking >> to fixed offsets. =C2=A0design a text format that is >> convenient to use instead of forcing the binary >> interface on everyone. > > thats a good idea. i'll look into it. should the descriptor be > presented in a decoded/splitted up form or just be the text > representation of the numerical values? i would hope the former; that's what i meant by design a text format that is convenient to use. ideally, cat /dev/gdt should give me something that is easily human-readable, and if i feed the lines back into /dev/gdt one at a time aux/lines /dev/gdt it should be valid input. >> also i wonder if this should really be in >> a separate ldt instead of polluting the gdt. > > older versions of glibc use an ldt entry per thread but it got > deprecated for tls use by set_thread_area wich works only with with > gdt entries. > > also ldt is not supported on amd64, but gdt segments are still > present and used for tls on linux. good to know; thanks. russ