Re: Understanding kexts in the early boot process
Re: Understanding kexts in the early boot process
- Subject: Re: Understanding kexts in the early boot process
- From: Thomas Tempelmann <email@hidden>
- Date: Sun, 14 Jun 2009 23:38:53 +0200
Michael,
thank you for helping me out here.
There's one thing left I don't understand yet:
>> Question 2: What if this file does not exist, can the system still
>> boot, and which component is then taking care of finding the kexts
>> (e.g. is it boot.efi or the kernel or what?)
>
> The bootloader is capable of parsing extension plists.
>> Question 4: How does the mkext, if loaded separately, get linked to
>> the kernel? (i.e. does the boot loader contain a linker that works
>> like the kextcache command?)
>
> The kernel contains a linker that handles this.
If the kernel contains a linker to link in the kexts, that means that
it's also the kernel that initializes them, I suppose. Correct?
However, on q 2 you replied that the bootloader parses kexts.
What I haven't seen yet is the part that links the kexts (apparently
loaded by the boot loader) to the kernel. Does the boot_args struct
have a new parameter (not doc'd in Amit's book) which passes a pointer
to a list of loaded kexts to the kernel, or how does this work?
Background is this: It appears that a 3rd party boot loader is able to
load two sets of kexts from different locations and get them used by
the kernel. I try to understand how that works, because so far all I
learned was that there's only one single group of kexts that the
kernel sees, not several.
--
Thomas Tempelmann, http://www.tempel.org/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden