>>3. What's the point in keeping sys/arch/i386/i386/pmapae.c? Are there any >>plans for re-enabling PAE support?
PAE will always be needed for 32bit processors as I understand it. There are some 32bit processors out there that the boards will allow for more than 4 gigs of ram But you will need PAE to actually see it. This used to be a big thing for SQL servers before everything went 64bit on that side. So why it may not be enabled by default its a quick option change to enable it if you ever need it. That is really the only one I could comment on with out looking like a complete tard. On Thu, Sep 29, 2011 at 4:41 PM, Vadim Zhukov <persg...@gmail.com> wrote: > Hello all. > > After some talks on opennet.ru I dived into the sys/uvm/ and other > places, having a few more or less tech-nical questions raised now. Can > anybody answer them? > > 1. amap_share_protect() in sys/uvm/uvm_amap.c is totally unused, is there > any point for keeping it around? > > 2. Am I right that W^X techniques like segment splitting on i386 are not > used in kernel? > > 2a. If yes, what's the main stopper here? > > 3. What's the point in keeping sys/arch/i386/i386/pmapae.c? Are there any > plans for re-enabling PAE support? > > 4. Stack gap limit (STACKGAP_RANDOM) on almost all archs is 256*1024 > (some use less). Are there any pitfalls in growing it on (64-bit) archs > like amd64, changing random bit count from 15 to something more > effective? > > Thanks in advance, and sorry for bothering, if any. > > -- > WBR, > Vadim Zhukov > > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > -- Defendere vivos a mortuis
