Re: b_freelist TAILQ/SLIST

[Konstantin Belousov]

On Fri, Jun 28, 2013 at 12:26:44AM +0300, Alexander Motin wrote:
> Hi.
> 
> While doing some profiles of GEOM/CAM IOPS scalability, on some test 
> patterns I've noticed serious congestion with spinning on global 
> pbuf_mtx mutex inside getpbuf() and relpbuf(). Since that code is 
> already very simple, I've tried to optimize probably the only thing 
> possible there: switch bswlist from TAILQ to SLIST. As I can see, 
> b_freelist field of struct buf is really used as TAILQ in some other 
> places, so I've just added another SLIST_ENTRY field. And result 
> appeared to be surprising -- I can no longer reproduce the issue at all. 
> May be it was just unlucky synchronization of specific test, but I've 
> seen in on two different systems and rechecked results with/without 
> patch three times.
This is too unbelievable.  Could it be, e.g. some cache line conflicts
which cause the trashing, in fact ? Does it help if you add void *b_pad
before b_freelist instead of adding b_freeslist ?

> 
> The present patch is here:
> http://people.freebsd.org/~mav/buf_slist.patch
> 
> The question is how to do it better? What is the KPI/KBI policy for 
> struct buf? I could replace b_freelist by a union and keep KBI, but 
> partially break KPI. Or I could add another field, probably breaking 
> KBI, but keeping KPI. Or I could do something handmade with no breakage. 
> Or this change is just a bad idea?
The same question about using union for b_freelist/b_freeslist, does the
effect of magically fixing the contention still there if b_freeslist
is on the same offset as the b_freelist ?

There are no K{B,P}I policy for struct buf in HEAD, just change it as
it fits.


pgpGt3DQKL6vB.pgp
Description: PGP signature

IPv6 - sobind fails with 49

[Sreenivasa Honnur]

I am writing a kernel socket program which binds to a IPv6 address, so bind 
always fails with 49. Below is the code snippet I am using, is something wrong 
here?



roundhay# uname -a

FreeBSD roundhay 9.1-RELEASE FreeBSD 9.1-RELEASE #2: Mon Apr  8 16:15:06 IST 
2013 
root@roundhay:/usr/obj/home/freebsd.org/sys/TOED
  amd64



Ifconfig/ping6 output:

==

cxgbe1: flags=8843 metric 0 mtu 1500


options=6c07bb

ether 00:07:43:11:89:88

inet6 2010::102 prefixlen 64

inet6 fe80::207:43ff:fe11:8988%cxgbe1 prefixlen 64 scopeid 0xd

inet6 fe80::1%cxgbe1 prefixlen 64 scopeid 0xd

nd6 options=21

media: Ethernet 10Gbase-SR 

status: active

roundhay# ping6 2010::101

PING6(56=40+8+8 bytes) 2010::102 --> 2010::101

16 bytes from 2010::101, icmp_seq=0 hlim=64 time=0.915 ms

16 bytes from 2010::101, icmp_seq=1 hlim=64 time=0.168 ms

^C

--- 2010::101 ping6 statistics ---

2 packets transmitted, 2 packets received, 0.0% packet loss

round-trip min/avg/max/std-dev = 0.168/0.541/0.915/0.374 ms





Code:

struct sockaddr_in6 saddr6;

rv = socreate(AF_INET6, &sock, SOCK_STREAM, IPPROTO_TCP,

td->td_ucred, td);



if (rv != 0) {

printf("sock create ipv6 %s failed %d.\n",

tbuf, rv);

return NULL;

}



saddr6.sin6_family = AF_INET6;

rv = inet_pton(AF_INET6, "2010::102", &saddr6.sin6_addr); ==> 
returns 1, which indicates it's a valid IPV6 address

printf("inet_pton retunred:%d\n", rv);



saddr6.sin6_port = htons(3260);

saddr6.sin6_len = sizeof(saddr6);



rv = sobind(sock, (struct sockaddr *)&saddr6, td); ==> fails 
with return value of 49



___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: expanding amd64 past the 1TB limit

[Oliver Pinter]

On 6/27/13, Chris Torek  wrote:
> OK, I wasted :-) way too much time, but here's a text file that
> can be comment-ified or stored somewhere alongside the code or
> whatever...
>
> (While drawing this I realized that there's at least one "wasted"
> page if the machine has .5 TB or less: we can just leave zero
> slots in the corresponding L4 direct-map entries.  But that would
> require switching to the bcopy() method also mentioned below.  Or
> indexing into vmspace0.vm_pmap.pm_pml4, which is basically the
> same thing.)
>
> Chris
>
> -
>
> There are six -- or sometimes five -- sets of pages allocated here
> at boot time to map physical memory in two ways.  Note that each
> page, regardless of level, stores 512 PTEs (or PDEs or PDPs, but
> let's just use PTE here and prefix it with "level" as needed: 4,
> 3, 2, or 1.)
>
> There is one page for the top level, L4, page table entries.  Each
> L4 PTE maps 512 GB of space.  Unless it's marked "invalid", no L4
> PTE can be marked "stop here": it either is marked as "this
> address is invalid", or it points to one physically-adressed page
> full of L3 PTEs.  Eventually, those L3 PTEs will map-or-reject
> half a terabyte.  512 entries, each mapping .5 TB, allow us to map
> 256 TB, which is as much as the hardware supports (there are, in
> effect, only 48 virtual address bits: the top 16 bits must match
> the 47th bit).
>
> The L4 entry halfway down, at PML4PML4I, is set to point back to
> this page itself; that's the "recursive page table" for user
> space, which we do nothing else with at boot time.
>
> We need (up to) NDMPML4E pages, each holding 512 L3 PTEs, for the
> direct map space.  If the processor supports 1 GB pages, an L3 PTE
> can be marked with "stop here" and these L3 PTEs each grant (or
> forbid) access to 1 GB of physical space at a time.  A system
> with, say, 3 GB of RAM starting at 0 can map it all with three L3
> PTEs: "address 0 is valid for 1GB", "address 1GB is valid for
> 1GB", "address 2GB is valid for 1GB".  The remaining L3 PTEs are
> zero, making the remaining address space invalid.
>
> If the processor does not support 1 GB pages, or if there is less
> than 1 GB of RAM "at the end" (e.g., if the system has 4.5 GB),
> the L3 PTEs may need to point to more pages holding L2 PTEs.
> These L2 PTEs always support 2 MB pages.  Each page of L2 PTEs
> maps 1 GB. So a machine with 4.5 GB and 1 GB mappings needs one L3
> page with four valid 1 GB L3 PTEs and then one L3 PTE pointing to
> one page of L2 PTEs.  That one page of L2 PTEs is half-filled,
> containing 256 2MB-sized PTEs, mapping the 512 MB.  The remaining
> half of that page is zero, making the remaining addresses invalid.
>
> Pictorially, and adding the names of the physical page(s), thus
> far we have this.  (Note, the L4 PTE page is drawn more than twice
> as tall as the L3 and L2 pages, just to get space for arrows.)
>
>   LEVEL 4:LEVEL 3: LEVEL 2:
>   _._
>   KPML4phys  v   \
>  +-+  |
>  |  0: |  |
>  |-|  |
>  |  1: |  | DMPDPphys  DMPDphys
>  (   ...   )  |.-> +-+ ++
>  | 127:|  |   /|  0: 0GB | .-> |  0: 4GB|
>  |-|  |  | |  1: 1GB |/|  1: 4GB+2MB|
>   PML4PML4I: | 128: *--|--/  | |  2: 2GB |   / |  2: 4GB+4MB|
>  |-| | |  3: 3GB |  /  (  ...   )
>  | 129:| | |  4:  *--|-/   | 255: 4.5GB-2MB |
>  |   ...   | | |  5: | | 256:   |
>      |-| | (   ...   ) | 257:   |
>  /  DMPML4I: |  *--|-/ | 511:| (  ...   )
>  NDMPML4E|-|   +-+ ++
>  \   |  *--|-> |   0:|
>  |-|   |   1:|
>| |   |   2:|  (These are used only
>  |-|   |   3:|   if the system has more
>  |   ...   |   (   ...   )   than 512 GB)
>  ( |-|  )| 509:|
>  ( | 510: see below )| 510:|
>  ( |-|  )| 511:|
>  ( | 511: see below )+-+
>+-+
>
> If the hardware supports 1GB pages, "ndm1g" is the number of
> gigabyte entries (4 in the example above).  Otherwise it's just
> zero.  Meanwhile "ndmpdp" is the number of gigabytes of RAM that
> need to be mapped, in this case 5.  Thus, if ndmpdp > ndm1g, we
> need ndmpdp-ndm1g pages to hold some L2 PTEs.
>
> Now we get to the weirder case of the kernel itself (both its
> non-direct-mapped dynamically allocated virtual memory, and its
> text/data/bss).  The branch offset limitations encourage the
> placement of the kern

Re: expanding amd64 past the 1TB limit

[Chris Torek]

OK, I wasted :-) way too much time, but here's a text file that
can be comment-ified or stored somewhere alongside the code or
whatever...

(While drawing this I realized that there's at least one "wasted"
page if the machine has .5 TB or less: we can just leave zero
slots in the corresponding L4 direct-map entries.  But that would
require switching to the bcopy() method also mentioned below.  Or
indexing into vmspace0.vm_pmap.pm_pml4, which is basically the
same thing.)

Chris

-

There are six -- or sometimes five -- sets of pages allocated here
at boot time to map physical memory in two ways.  Note that each
page, regardless of level, stores 512 PTEs (or PDEs or PDPs, but
let's just use PTE here and prefix it with "level" as needed: 4,
3, 2, or 1.)

There is one page for the top level, L4, page table entries.  Each
L4 PTE maps 512 GB of space.  Unless it's marked "invalid", no L4
PTE can be marked "stop here": it either is marked as "this
address is invalid", or it points to one physically-adressed page
full of L3 PTEs.  Eventually, those L3 PTEs will map-or-reject
half a terabyte.  512 entries, each mapping .5 TB, allow us to map
256 TB, which is as much as the hardware supports (there are, in
effect, only 48 virtual address bits: the top 16 bits must match
the 47th bit).

The L4 entry halfway down, at PML4PML4I, is set to point back to
this page itself; that's the "recursive page table" for user
space, which we do nothing else with at boot time.

We need (up to) NDMPML4E pages, each holding 512 L3 PTEs, for the
direct map space.  If the processor supports 1 GB pages, an L3 PTE
can be marked with "stop here" and these L3 PTEs each grant (or
forbid) access to 1 GB of physical space at a time.  A system
with, say, 3 GB of RAM starting at 0 can map it all with three L3
PTEs: "address 0 is valid for 1GB", "address 1GB is valid for
1GB", "address 2GB is valid for 1GB".  The remaining L3 PTEs are
zero, making the remaining address space invalid.

If the processor does not support 1 GB pages, or if there is less
than 1 GB of RAM "at the end" (e.g., if the system has 4.5 GB),
the L3 PTEs may need to point to more pages holding L2 PTEs.
These L2 PTEs always support 2 MB pages.  Each page of L2 PTEs
maps 1 GB. So a machine with 4.5 GB and 1 GB mappings needs one L3
page with four valid 1 GB L3 PTEs and then one L3 PTE pointing to
one page of L2 PTEs.  That one page of L2 PTEs is half-filled,
containing 256 2MB-sized PTEs, mapping the 512 MB.  The remaining
half of that page is zero, making the remaining addresses invalid.

Pictorially, and adding the names of the physical page(s), thus
far we have this.  (Note, the L4 PTE page is drawn more than twice
as tall as the L3 and L2 pages, just to get space for arrows.)

  LEVEL 4:LEVEL 3: LEVEL 2:
  _._
  KPML4phys  v   \
 +-+  |
 |  0: |  |
 |-|  |
 |  1: |  | DMPDPphys  DMPDphys
 (   ...   )  |.-> +-+ ++
 | 127:|  |   /|  0: 0GB | .-> |  0: 4GB|
 |-|  |  | |  1: 1GB |/|  1: 4GB+2MB|
  PML4PML4I: | 128: *--|--/  | |  2: 2GB |   / |  2: 4GB+4MB|
 |-| | |  3: 3GB |  /  (  ...   )
 | 129:| | |  4:  *--|-/   | 255: 4.5GB-2MB |
 |   ...   | | |  5: | | 256:   |
     |-| | (   ...   ) | 257:   |
 /  DMPML4I: |  *--|-/ | 511:| (  ...   )
 NDMPML4E|-|   +-+ ++
 \   |  *--|-> |   0:|
 |-|   |   1:|
 | |   |   2:|  (These are used only
 |-|   |   3:|   if the system has more
 |   ...   |   (   ...   )   than 512 GB)
   ( |-|  )| 509:|
   ( | 510: see below )| 510:|
   ( |-|  )| 511:|
   ( | 511: see below )+-+
 +-+

If the hardware supports 1GB pages, "ndm1g" is the number of
gigabyte entries (4 in the example above).  Otherwise it's just
zero.  Meanwhile "ndmpdp" is the number of gigabytes of RAM that
need to be mapped, in this case 5.  Thus, if ndmpdp > ndm1g, we
need ndmpdp-ndm1g pages to hold some L2 PTEs.

Now we get to the weirder case of the kernel itself (both its
non-direct-mapped dynamically allocated virtual memory, and its
text/data/bss).  The branch offset limitations encourage the
placement of the kernel's text, etc., in the last 2 GB of virtual
space, i.e., starting at 0x..f800..  But, we want
a reasonable amount of room for dynamic VM.  So we give the kernel
at least 512 GB of VM -- t

b_freelist TAILQ/SLIST

[Alexander Motin]

Hi.

While doing some profiles of GEOM/CAM IOPS scalability, on some test 
patterns I've noticed serious congestion with spinning on global 
pbuf_mtx mutex inside getpbuf() and relpbuf(). Since that code is 
already very simple, I've tried to optimize probably the only thing 
possible there: switch bswlist from TAILQ to SLIST. As I can see, 
b_freelist field of struct buf is really used as TAILQ in some other 
places, so I've just added another SLIST_ENTRY field. And result 
appeared to be surprising -- I can no longer reproduce the issue at all. 
May be it was just unlucky synchronization of specific test, but I've 
seen in on two different systems and rechecked results with/without 
patch three times.


The present patch is here:
http://people.freebsd.org/~mav/buf_slist.patch

The question is how to do it better? What is the KPI/KBI policy for 
struct buf? I could replace b_freelist by a union and keep KBI, but 
partially break KPI. Or I could add another field, probably breaking 
KBI, but keeping KPI. Or I could do something handmade with no breakage. 
Or this change is just a bad idea?


--
Alexander Motin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: BUS_PROBE_NOWILDCARD behaviour doesn't seem to match DEVICE_PROBE(9)

[John Baldwin]

On Thursday, June 20, 2013 10:54:39 am Ryan Stone wrote:
> 
http://www.freebsd.org/cgi/man.cgi?query=DEVICE_PROBE&apropos=0&sektion=0&manpath=FreeBSD%208.2-
RELEASE&format=html
> 
> DEVICE_PROBE(9) has this to say about BUS_PROBE_NOWILDCARD:
> 
> The driver expects its parent to tell it which children to manage and no
> probing is really done. The device only matches if its parent bus
> specifically said to use this driver.

Perhaps run this by Warner to make sure?  (There is also a new-bus@ list FYI).

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Exposing driver's GPIOs through gpiobus

[John Baldwin]

On Wednesday, June 12, 2013 11:36:04 pm Ryan Stone wrote:
> At $WORK we have some custom boards with multi-port uarts managed by puc.
> The uart devices happen to provide some GPIOs, and our hardware designers
> have appropriated those GPIOs for various purposes entirely unrelated to
> the uart.
> 
> I'm looking for a clean way to provide access to the GPIOs.  It occurred to
> me that this was a problem that should be solved through newbus, and lo and
> behold I have discovered that FreeBSD provides a gpiobus driver that seems
> suitable.  I've been playing around with this for a couple of days and I
> have a solutions that is working, but there are aspects that I am unhappy
> with.  I also quite unfamiliar with newbus, so there easily could be better
> ways to approach the problem that I haven't thought of.
> 
> What I ended up doing was making gpiobus and gpioc children of the puc
> bus.  In puc_bfe_attach() I create two new child devices of the puc device
> with device_add_child(), one with the gpioc devclass and one with the
> gpiobus devclass.  I then attach both children with
> device_probe_and_attach().  I make the puc_pci driver itself provide
> implementations of the various gpio methods (like gpio_pin_get) so they can
> be inherited by the child devices.
> 
> Things start to get somewhat messy in the gpio client code.  I have the
> same image running on many different hardware types, so I can't use device
> hints to create a child device of the gpiobus.  Instead my kernel module
> tracks down the device_t for the puc, finds the gpiobus child, and uses
> BUS_ADD_CHILD to create a child of the gpiobus.  I had to add a new gpiobus
> method to allocate GPIO pins to my driver instance.  Once that's done, I
> can toggle GPIOs and whatnot using methods on my driver instance.
> 
> The things that I'm most unhappy with (newbus-wise, anyway) are:
> 
> 1) By default the gpioc and gpiobus drivers were claiming the uart children
> of the puc.  I had to decrease their priority in bus_probe to
> BUS_PROBE_LOW_PRIORITY to work around the problem.  I really don't think
> that was the right solution.  I guess I could introduce a new device that
> is a child of the puc, make sure that it will not claim the uarts, and then
> make the gpioc and gpiobus children of this device.
> 
> 2) I'm not sure how to clean up my child device when my module is
> unloaded.  Currently I am checking if it already exists on load and reusing
> it if so.  I may be missing something obvious here.

Just leave the device around and reuse it.  In your identify routine do
something like this:

static void
agp_i810_identify(driver_t *driver, device_t parent)
{

if (device_find_child(parent, "agp", -1) == NULL &&
agp_i810_match(parent))
device_add_child(parent, "agp", -1);
}

> 
> 3) I really don't like the way that I am adding my child to gpiobus.  Upon
> writing this it occurs to me that device_identify would be the canonical
> way to do this.  Previously it wasn't clear to me how to fit
> device_identify into the current architecture of the gpio client but I see
> how it can be done now.

Yes, device_identify is what you want.  I think it will also solve problem 1
for you as well.

-- 
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Can't use gcc in a clang built world

[Dimitry Andric]

On Jun 27, 2013, at 20:48, Andrew Turner  wrote:
> On Thu, 27 Jun 2013 13:06:07 +0200
> Dimitry Andric  wrote:
> 
>> On 2013-06-27 02:02, Kevin Day wrote:
>>> Are you supposed to be able to use gcc to build userland binaries
>>> if you built world with clang?
>>> 
>>> I'm on -CURRENT as of a few days ago (using armv6 but i'm not sure
>>> if that matters).
>> 
>> Yes, the arch matters a lot.  For arm, adding __clear_cache() to
>> libgcc was explicitly disabled by Andrew here:
>> 
>> http://svnweb.freebsd.org/base?view=revision&revision=244382
>> 
>> "Don't provide clear_cache or the __sync_* functions on ARM with clang
>> as they are provided by clang as builtin functions."
>> 
>> Maybe those functions should be in libgcc after all, if other programs
>> depend on this.
> 
> The reason to disable __clear_cache is incorrect in r244382 as it is a
> builtin in clang, but calls into an external copy of __clear_cache. The
> reason __clear_cache was disabled was because of a bug in clang where
> it is unable to compile a builtin function, however I only found this
> out recently.
> 
> The issue with clang has been fixed, and, as of r251791 __clear_cache
> is enabled in compiler-rt.


Okay, but apparently compilers such as gcc do not use compiler-rt at
all, but expect the function to be available in libgcc instead.

So since clang can compile the definition on arm now, shall we re-enable
it for libgcc too?

-Dimitry

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Can't use gcc in a clang built world

[Andrew Turner]

On Thu, 27 Jun 2013 13:06:07 +0200
Dimitry Andric  wrote:

> On 2013-06-27 02:02, Kevin Day wrote:
> > Are you supposed to be able to use gcc to build userland binaries
> > if you built world with clang?
> >
> > I'm on -CURRENT as of a few days ago (using armv6 but i'm not sure
> > if that matters).
> 
> Yes, the arch matters a lot.  For arm, adding __clear_cache() to
> libgcc was explicitly disabled by Andrew here:
> 
> http://svnweb.freebsd.org/base?view=revision&revision=244382
> 
> "Don't provide clear_cache or the __sync_* functions on ARM with clang
> as they are provided by clang as builtin functions."
> 
> Maybe those functions should be in libgcc after all, if other programs
> depend on this.

The reason to disable __clear_cache is incorrect in r244382 as it is a
builtin in clang, but calls into an external copy of __clear_cache. The
reason __clear_cache was disabled was because of a bug in clang where
it is unable to compile a builtin function, however I only found this
out recently.

The issue with clang has been fixed, and, as of r251791 __clear_cache
is enabled in compiler-rt.

Andrew
> 
> -Dimitry
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscr...@freebsd.org"
> 
> 

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: expanding amd64 past the 1TB limit

[Chris Torek]

>> .. (but I still needed the map I drew of the page tables...).

>care to share? :-)

It's on paper (I need to get a whiteboard...).  If I can ASCIIfy it ...

Chris
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: bsd boot sequence

[Warren Block]

On Thu, 27 Jun 2013, Brian Kim wrote:


To start, I was wondering if someone could briefly explain the operations
and function calls that occur at boot time. I wish to thoroughly examine
the freebsd source code but I'm afraid the sheer volume of code that exists
leaves me with no real starting point for my research.


These should be a start.

man 8 boot
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/boot.html
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Can't use gcc in a clang built world

[Dimitry Andric]

On 2013-06-27 02:02, Kevin Day wrote:

Are you supposed to be able to use gcc to build userland binaries if you built 
world with clang?

I'm on -CURRENT as of a few days ago (using armv6 but i'm not sure if that 
matters).


Yes, the arch matters a lot.  For arm, adding __clear_cache() to libgcc
was explicitly disabled by Andrew here:

http://svnweb.freebsd.org/base?view=revision&revision=244382

"Don't provide clear_cache or the __sync_* functions on ARM with clang
as they are provided by clang as builtin functions."

Maybe those functions should be in libgcc after all, if other programs
depend on this.

-Dimitry
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

bsd boot sequence

[Brian Kim]

howdy all,

As a junior computer engineering major who has dreams of developing an
operating system more ubiquitous than ms windows, I have come to appreciate
the complexity and elegance of both the freebsd os and community. While
achieving proficiency in C programming yet lacking in both UNIX utility
know-how and shell scripting, I would rate my hacker savvy to be on an
intermediate level. By the time I graduate from college, I hope to have a
thorough understanding of the bsd kernel on the lowest level.

Don't get me wrong though: while my end-game may be to develop my own
operating system, I will forever be a contributor to freebsd. As my
understanding of computers develops, you will undoubtedly see my name
appear more frequently on the freebsd-hacker emails. Unfortunately, I am
just not at the level of understanding just yet.

To start, I was wondering if someone could briefly explain the operations
and function calls that occur at boot time. I wish to thoroughly examine
the freebsd source code but I'm afraid the sheer volume of code that exists
leaves me with no real starting point for my research.

Thank you all for your time.

-- 
Best Wishes,
Brian Kim
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: expanding amd64 past the 1TB limit

[Julian Elischer]

On 6/27/13 12:11 AM, Chris Torek wrote:
[...]

them (but I still needed the map I drew of the page tables...).

care to share? :-)

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"