Contribute
Register

Difference between kexts in /Extra and /S/L/E

Status
Not open for further replies.
Joined
Aug 12, 2010
Messages
1,575
Motherboard
X58A-UD3R v2
CPU
i7-930
Graphics
5770
Mac
  1. MacBook
  2. MacBook Pro
Mobile Phone
  1. Android
Hi guys,

I was wondering what the difference was between installing a kext in /Extra/Extensions rather thean /System/Library/Extensions ? I know that by keeping the kexts in /Extra it stops them being written over when you do a system update but what determines if a kext can live in /E/E instead of /S/L/E?

Is it also allowing the kext not to have it's permissions fixed and still be run in OSX?
 
notshy said:
Hi guys,

I was wondering what the difference was between installing a kext in /Extra/Extensions rather thean /System/Library/Extensions ? I know that by keeping the kexts in /Extra it stops them being written over when you do a system update but what determines if a kext can live in /E/E instead of /S/L/E?

Is it also allowing the kext not to have it's permissions fixed and still be run in OSX?
Some kexts can only be installed and run from /S/L/E. Examples of this is network and USB 3.0. Most other Hackintosh kexts can safely be run from /E/E. Any kext, regardless of where it is installed MUST be owned by root:wheel (0:0). If it isn't, it will never be used.
 
MacMan said:
notshy said:
Hi guys,

I was wondering what the difference was between installing a kext in /Extra/Extensions rather thean /System/Library/Extensions ? I know that by keeping the kexts in /Extra it stops them being written over when you do a system update but what determines if a kext can live in /E/E instead of /S/L/E?

Is it also allowing the kext not to have it's permissions fixed and still be run in OSX?
Some kexts can only be installed and run from /S/L/E. Examples of this is network and USB 3.0. Most other Hackintosh kexts can safely be run from /E/E. Any kext, regardless of where it is installed MUST be owned by root:wheel (0:0). If it isn't, it will never be used.

Hey MacMan,
Thanks for the info. I was just wondering what it was in the kext that meant some could be in /E/E. For example one of the guys on my bluetooth thread posted a kext that tricks OSX into thinking that you dongle is a real mac internal bluetooth chip via adding your dongles IDs to this custom kext. My guide involved editing the actual IOBluetoothFamily kext where as this one seems a bit cleaner as you can have the original vanilla mac IOBluetooth kext and just add your IDs to this second one. Anyway - the second one can be run from /E/E as well as /S/L/E and I was just wondering what it was that meant that some hack kexts had to be run from S/L/E but others could be run from /E/E. Is it harder in the design of the kext to run it from /E/E? Why won't all hacked kexts run from /E/E. For example FakeSMC updates started off in /S/L/E and then on further updates they could be moved to /E/E

No worries if I'm being a bit pedantic here and I'll shut up.
 
notshy said:
Hey MacMan,
Thanks for the info. I was just wondering what it was in the kext that meant some could be in /E/E. For example one of the guys on my bluetooth thread posted a kext that tricks OSX into thinking that you dongle is a real mac internal bluetooth chip via adding your dongles IDs to this custom kext. My guide involved editing the actual IOBluetoothFamily kext where as this one seems a bit cleaner as you can have the original vanilla mac IOBluetooth kext and just add your IDs to this second one. Anyway - the second one can be run from /E/E as well as /S/L/E and I was just wondering what it was that meant that some hack kexts had to be run from S/L/E but others could be run from /E/E. Is it harder in the design of the kext to run it from /E/E? Why won't all hacked kexts run from /E/E. For example FakeSMC updates started off in /S/L/E and then on further updates they could be moved to /E/E

No worries if I'm being a bit pedantic here and I'll shut up.
It all depends on dependencies in the kext.
 
Status
Not open for further replies.
Back
Top