From owner-freebsd-hackers  Sun Jan 21 10:42:09 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA29978
          for hackers-outgoing; Sun, 21 Jan 1996 10:42:09 -0800 (PST)
Received: from mandor.dev.com (mandor.dev.com [198.145.93.1])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA29963
          for <freebsd-hackers@FreeBSD.ORG>; Sun, 21 Jan 1996 10:42:05 -0800 (PST)
Received: from mandor.dev.com (localhost [127.0.0.1]) by mandor.dev.com (8.7.3/8.7.3) with ESMTP id KAA07162; Sun, 21 Jan 1996 10:37:26 -0800 (PST)
Message-Id: <199601211837.KAA07162@mandor.dev.com>
To: Bruce Evans <bde@zeta.org.au>
cc: freebsd-hackers@FreeBSD.ORG
Subject: Re: USER_LDT limit 
Date: Sun, 21 Jan 1996 10:37:26 PST
From: Brian Smith <brians@mandor.dev.com>
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

In message <199601211254.XAA10974@godzilla.zeta.org.au>, Bruce Evans writes:
>>I'm playing with Wine for FreeBSD 2.1, and found something odd.  In
>>/usr/src/sys/i386/i386/sys_machdep.c, I see that the descriptor maximum
>>allowed in i386_set_ldt() is 512, which isn't strange.  What is surprising
>>is that it isn't a macro define.  Is the number 512 magic? I'd like to
>
>I think it is just bad programming.  The power of 2 size is good for
>avoiding memory wastage.  However, malloc() would better than kmem_malloc()
>here since malloc() provides statistics.  However^2, the amount of memory
>is fairly large and it is per-process, so it should be pageable.  Can
>the vm system page user LDT's?

It should be able to page LDT's.  Descriptor tables are located in linear
memory, which means that paging should work just fine.  Paging tables
are the ones which are harder to page in/out.  As to what FreeBSD can
do... I'm still reading source (and probably will be for a time).  :-)

Brian