DriverKit Port #139
Comments
|
starting my fork here |
|
I have a working DriverKit networking driver for RNDIS, ECM, NCM, EEM etc.
I hope to make it available in the Mac store eventually. But can make it
available to HoRNDIS users to use now, just finalizing the Installation
application.
I have the same issue with VID/PID's, I need to request each pair
individually from Apple. Although I have my own VID (0x15ec) that I can
allocate any PID with.
If anyone wants to try it contact me with the VID/PID you need.
…On Thu, Apr 22, 2021 at 2:02 PM sgulls ***@***.***> wrote:
Clearly the writing is on the wall for KEXTs. We can get away with it for
now by running bputil -k in 1TR for arm Macs but sooner or later KEXTs
are going to go the way of 32 bit support and it's clear the original
developer/maintainer cannot/will not port the code so it's up to us
honestly.
I'm not that experienced with Obj-C and I've played around with the code
but not everything has a drop in replacement from kernel IOKit to DriverKit
so I'm in way over my head.
among some libraries/headers that I'm figuring out how to replace
In the headers file:
IOKit/usb/IOUSBHostFamily.h
IOKit/network/IOEthernetController.h &
IOKit/network/IOEthernetController.h (I guess IOUserNetworkEthernet is
probably the way to go but it's not quite the same)
IOKit/IOTimerEventSource.h
IOKit/IOMessage.h
in the main cpp file:
mach/kmod.h & libkern/version.h (they don't seem necessary given we're
moving code away from the kernel)
IOKit/network/IOGatedOutputQueue.h
In addition, DriverKit now enumerates interfaces using a c++ class in an
.iig file which handles starting, stopping and cleanup versus the kext
which has everything in the .cpp body so reformatting the code will be
necessary.
I only have DriverKit entitlements for a few VID/PIDs as I have to request
each pair individually from Apple so I only bothered request devices I
personally own. With that being said, an unsigned driver extension is
vastly preferably to running in the kernel as evidenced by the kernel
panics and crashes this software has wrought so far.
Anyone with any Obj-C experience willing to pitch in? I'll try learning as
I go but I can't do this by myself.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#139>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALJH5CIUKEFVZN4U3J4DSDTKCFFPANCNFSM43NLL5EQ>
.
--
Belcarra Embedded USB Software
Stuart_Lynne ***@***.***> 604-461-7532
Alternates: 604-283-7475 and 604-518-1749(cell)
http://usblan.belcarra.com http://www.belcarra.com
|
|
Here's a dumb question: can you use DriverKit for the network portion, and libusb for the USB portion? For a while I was thinking that the future of HoRNDIS would be tun/tap-based for network and libusb for USB. |
|
@Belcarra that sounds great! When are you planning to release it? @sgulls I have looked at your repository and have noticed that you added code for a SwiftUI App. What was your plan? How far did you come porting it to DriverKit? |
|
On Thu, Jun 10, 2021 at 6:54 AM Konstantin Wachendorff < ***@***.***> wrote:
@Belcarra <https://github.com/Belcarra> that sounds great! When are you
planning to release it?
Currently getting ready to test with Monterey.
Last year Apple changed the NetworkingDriverkit API in an incompatible
manner that forces me to compile and build separate driverkit extensions
for Catalina and BigSur. Complicated by having to actually compile the
Catalina version using Xcode-11 on an Intel Mac because Xcode-12 does not
have the older Catalina version of the Driverkit APIs ...
Here's hoping that they have not made more changes in the Monterey APIs.
There are also some runtime issues WRT to activation and deactivation of
driver extensions in Catalina. So the Mac App which contains the extension
needs to work differently in Catalina.
I have entitlements for the Belcarra vendor ID (0x15ec) and I can generate
kits that use that vendor id and any product id. So if you can set a
specific vid/pid in your device I can produce test kits using that vendor
id.
If you own a USB Vendor ID Apple will grant entitlement for the Vendor ID
(you can use any product id.) If you don't own the Vendor ID but have
permission from the owner then Apple will grant entitlement for specific
Vendor/Product ID pairs.
I have requested USB entitlements for vendor/product ids 0x049f/0x505a and
0x0525/0xa4a2. Usually takes Apple between four and eight weeks to respond.
Hopefully, they will grant them.
… @sgulls <https://github.com/sgulls> I have looked at your repository and
have noticed that you added code for a SwiftUI App. What was your plan? How
far did you come porting it to DriverKit?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#139 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AALJH5APDRQPRM77243BYWTTSC7Z5ANCNFSM43NLL5EQ>
.
--
Belcarra Embedded USB Software
Stuart_Lynne ***@***.***> 604-461-7532
Alternates: 604-283-7475 and 604-518-1749(cell)
http://usblan.belcarra.com http://www.belcarra.com
|
Great initiative! Is your version working on M1 Big Sur? |
|
@Belcarra Any news about this ? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Clearly the writing is on the wall for KEXTs. We can get away with it for now by running
bputil -kin 1TR for arm Macs but sooner or later KEXTs are going to go the way of 32 bit support and it's clear the original developer/maintainer cannot/will not port the code so it's up to us honestly.I'm not that experienced with Obj-C and I've played around with the code but not everything has a drop in replacement from kernel IOKit to DriverKit so I'm in way over my head.
among some libraries/headers that I'm figuring out how to replace
In the headers file:
IOKit/usb/IOUSBHostFamily.hIOKit/network/IOEthernetController.h&IOKit/network/IOEthernetController.h(I guessIOUserNetworkEthernetis probably the way to go but it's not quite the same)IOKit/IOTimerEventSource.hIOKit/IOMessage.hin the main cpp file:
mach/kmod.h&libkern/version.h(they don't seem necessary given we're moving code away from the kernel)IOKit/network/IOGatedOutputQueue.hIn addition, DriverKit now enumerates interfaces using a c++ class in an
.iigfile which handles starting, stopping and cleanup versus the kext which has everything in the.cppbody so reformatting the code will be necessary.I only have DriverKit entitlements for a few VID/PIDs as I have to request each pair individually from Apple so I only bothered request devices I personally own. With that being said, an unsigned driver extension is vastly preferably to running in the kernel as evidenced by the kernel panics and crashes this software has wrought so far.
Anyone with any Obj-C experience willing to pitch in? I'll try learning as I go but I can't do this by myself.
The text was updated successfully, but these errors were encountered: