January 2002 - Darwin-kernel

Re: detaching ethernet interfaces..
by Justin C. Walker 25 Jan '02

25 Jan '02

On Friday, January 25, 2002, at 12:53 PM, Andrew Gallatin wrote: Is it possible to detach an ethernet interface in 10.1 / Darwin 1.4 after it has been ifconfig'ed up? (and down again) Eg, looking at the source code for ether_attach_inet, I see: /* XXX avoid free'ing the interface */ ifp->if_eflags |= IFEF_DETACH_DISABLED; I don't see IFEF_DETACH_DISABLED being cleared anywhere. So it looks as though an interface becomes unloadable once its been configured. Is this true? Why?? You mean "un-unloadable", right? It is true. Currently, while you can unload drivers in general, Darwin doesn't have the necessary mechanisms to run down all the stashed copies of the pointer to the driver's 'ifnet' structure. Therefore, if we did allow unloading, it would likely to come back to haunt us (in the form of a DSI, or other nasty surprise, when referencing a location that's no longer valid in kernel memory). Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | If you're not confused, | You're not paying attention *--------------------------------------*-------------------------------*

1 0

detaching ethernet interfaces..
by Andrew Gallatin 25 Jan '02

25 Jan '02

Is it possible to detach an ethernet interface in 10.1 / Darwin 1.4 after it has been ifconfig'ed up? (and down again) Eg, looking at the source code for ether_attach_inet, I see: /* XXX avoid free'ing the interface */ ifp->if_eflags |= IFEF_DETACH_DISABLED; I don't see IFEF_DETACH_DISABLED being cleared anywhere. So it looks as though an interface becomes unloadable once its been configured. Is this true? Why?? Thanks, Drew

1 0

Re: Kernel Panic
by Justin C. Walker 25 Jan '02

25 Jan '02

On Thursday, January 24, 2002, at 05:39 PM, Andrei Nikonov wrote: Hello! Recently I had a Kernel Panic, with some problem connected to WAITING FOR THE REMOTE DEBUGGER. I have Mac Os X system 10.1, but by that time I hadnt installed the Developer Tools, and tried to install some application such as NCBI toolkit, in other words i tried to compile without compilator. But now i stalled the Developer tools and got working NCBI toolkit, i have no more Kernel Panic. Can You explain me if that was a cause of panic or it is something else? We can't explain any of this to you without something substantive to go on. What was the panic message? It's possible that the lack of the toolkit caused a problem, but I don't know what the NCBI toolkit is, so I can't be sure. However, I'd hazzard a guess that the panic is not related to the lack of this toolkit. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Men are from Earth. | Women are from Earth. | Deal with it. *--------------------------------------*-------------------------------*

1 0

Kernel Panic
by Andrei Nikonov 25 Jan '02

25 Jan '02

Hello! Recently I had a Kernel Panic, with some problem connected to WAITING FOR THE REMOTE DEBUGGER. I have Mac Os X system 10.1, but by that time I hadnt installed the Developer Tools, and tried to install some application such as NCBI toolkit, in other words i tried to compile without compilator. But now i stalled the Developer tools and got working NCBI toolkit, i have no more Kernel Panic. Can You explain me if that was a cause of panic or it is something else? Andrei Andrei Nikonov Gene Technology tel. +372 56 9 85 85 3

1 0

Re: detecting airport cards
by Brian Wotring 24 Jan '02

24 Jan '02

Oy! The BSD/ifnet mechanisms don't currently give you that kind of detail. You'd have to get that from IOKit, and I don't know whether there is any standard way of representing wireless devices that IOKit knows about (Dean/Godfrey?). This is what 'ioreg' shows for Airport: | | | +-o radio@30000 <class AppleMacIODevice> | | | | +-o AirPortDriver <class AirPortDriver> | | | | +-o IOEthernetInterface <class IOEthernetInterface> | | | | | +-o IONetworkStack <class IONetworkStack> | | | | | +-o IONetworkStackUserClient <class IONetworkStackUserClient> | | | | +-o AirPortUserClient <class AirPortUserClient> | | | | +-o AirPortUserClient <class AirPortUserClient> 'airport' isn't going to work; and I don't know whether all wireless devices show up as 'radio'. What are you trying to do? There are some security concerns I am trying to address. The logic in my code will vary depending upon whether or not a net device I attach to is a wireless card or not. So there isn't any way to determine this inside a data link NKE? -- Brian Wotring ( brian(a)shmoo.com ) PGP KeyID: 0x9674763D

1 0

Re: detecting airport cards
by Justin C. Walker 24 Jan '02

24 Jan '02

Oy! The BSD/ifnet mechanisms don't currently give you that kind of detail. You'd have to get that from IOKit, and I don't know whether there is any standard way of representing wireless devices that IOKit knows about (Dean/Godfrey?). This is what 'ioreg' shows for Airport: | | | +-o radio@30000 <class AppleMacIODevice> | | | | +-o AirPortDriver <class AirPortDriver> | | | | +-o IOEthernetInterface <class IOEthernetInterface> | | | | | +-o IONetworkStack <class IONetworkStack> | | | | | +-o IONetworkStackUserClient <class IONetworkStackUserClient> | | | | +-o AirPortUserClient <class AirPortUserClient> | | | | +-o AirPortUserClient <class AirPortUserClient> 'airport' isn't going to work; and I don't know whether all wireless devices show up as 'radio'. What are you trying to do? Regards, Justin On Thursday, January 24, 2002, at 09:29 AM, Brian Wotring wrote: In my NKE, is there a way to obtain information about the network interfaces, specifically, which ones are wireless cards? -- Brian Wotring ( brian(a)shmoo.com ) PGP KeyID: 0x9674763D _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. -- /~\ The ASCII Justin C. Walker, Curmudgeon-at-Large \ / Ribbon Campaign X Help cure HTML Email / \

1 0

detecting airport cards
by Brian Wotring 24 Jan '02

24 Jan '02

In my NKE, is there a way to obtain information about the network interfaces, specifically, which ones are wireless cards? -- Brian Wotring ( brian(a)shmoo.com ) PGP KeyID: 0x9674763D

1 0

wiring/unwiring memory
by Andrew Gallatin 17 Jan '02

17 Jan '02

I've ported an OS-bypass network driver to Darwin / OS-X. However, I have one serious problem that I need advice on. The driver wires memory for user-level applications. These apps use this memory for communications with other nodes on the network (send/recv from/to the wired memory, no kernel involvement once the wiring is setup, similar to VI). The sequence of events is that the app mallocs some memory, ioctl's the driver to get it wired (the driver also gets the DMA handle to the physical memory & tells the nic about it). The app then communicates using the wired memory. Sometime later, the app ioctl's the driver, which shoots down the nic's association with that dma handle & unwires the memory. The app then frees the memory. Right now I'm using IOMemoryDescriptor::withAddress() to get a memory descriptor for the user's memory & using prepare() to wire it, and complete() to unwire it. This works quite well in the common case. However, a poorly written app which free's the memory prior to deregistering it will end up waiting forever in vm_map_delete() for the driver to unwire the memory. The driver has no idea the app tried to free the memory, so it will never unwire it. I'd like to have the user app be able to free the memory, but have the driver be able to hold onto it until the unwiring happens (in the worst case, close on the special device will trigger the driver to tear down everything). Are there any manipulations I can do from within IOKit to achieve this? Thanks for the advice.. Drew

1 0

Re: IOKit objects are they loaded into a contiguous memory segment?
by Shawn Erickson 13 Jan '02

13 Jan '02

On Sunday, January 13, 2002, at 11:22 AM, Dean Reece wrote: Shawn, Your static "unsigned short code01[]" will be virtually contiguous (in the kernel task), but is not guaranteed to be physically contiguous. >From your comment "I have to DMA in chunks smaller then the whole firmware image" I'm a bit confused. It sounds like you don't really need a physically contiguous buffer. Correct. I was just trying to understand if I would have to modify my current downloader code to handle physically non-contiguous firmware images. Also for some versions of the adapters I can DMA the whole firmware image at once others have DMA limitations that don't allow for that. An IOMemoryDescriptor is suitable for wrapping the static "unsigned short code01[]" directly, if you can handle the fact that it may not all be physically contiguous. In that case, getPhysicalSegment will walk you through the segments. You'll find that the segments are all multiples of 4K (page size), except the first and last which may be partial pages. Great, what I thought it would do. In any event, once the firmware is downloaded, you should be able to free up this image (and any copies). Reducing your steady-state wired memory footprint is much more important than trimming the peak footprint used during device initialization. Yup... I was mostly trying to reduce the memory copy overhead which is around 350 KB for each adapter installed in the system. Not sure it is worth it if I end up downloading firmware in page size chunks... I need to think about this a little more. Cheers, - Dean On Sunday, January 13, 2002, at 11:01 AM, Shawn Erickson wrote: I was in the process of doing some driver optimization... I can reduce the amount of kernel memory used and memory copy times iff it is safe to assume IOKit objects are allocated into contiguous physical memory segments. To better explain... I have a firmware driver object that contains a firmware image ( unsigned short code01[] = { ...image..}; ) that a secondary driver we get a pointer to and then download this firmware to my adapter (adapter DMAs the firmware from the physical address I pass it). Currently I have the secondary driver allocate a contiguous memory segment and copy the image into that segment. I would like to avoid this if possible. Is it safe to simply allocate an IOMemoryDescriptor with a pointer to the image and the images length then call getPhysicalSegment to get the start of next segment I want the adapter to download (I have to DMA in chunks smaller then the whole firmware image). I think I know the answer but I keep swapping between working on different OSes (Window NT/2000, Solaris, Mac OS, and Mac OS X) and it becomes hard to keep things straight :{ .... so I thought I better ask to make sure.

1 0

Re: IOKit objects are they loaded into a contiguous memory segment?
by Dean Reece 13 Jan '02

13 Jan '02

Shawn, Your static "unsigned short code01[]" will be virtually contiguous (in the kernel task), but is not guaranteed to be physically contiguous. >From your comment "I have to DMA in chunks smaller then the whole firmware image" I'm a bit confused. It sounds like you don't really need a physically contiguous buffer. An IOMemoryDescriptor is suitable for wrapping the static "unsigned short code01[]" directly, if you can handle the fact that it may not all be physically contiguous. In that case, getPhysicalSegment will walk you through the segments. You'll find that the segments are all multiples of 4K (page size), except the first and last which may be partial pages. In any event, once the firmware is downloaded, you should be able to free up this image (and any copies). Reducing your steady-state wired memory footprint is much more important than trimming the peak footprint used during device initialization. Cheers, - Dean On Sunday, January 13, 2002, at 11:01 AM, Shawn Erickson wrote: I was in the process of doing some driver optimization... I can reduce the amount of kernel memory used and memory copy times iff it is safe to assume IOKit objects are allocated into contiguous physical memory segments. To better explain... I have a firmware driver object that contains a firmware image ( unsigned short code01[] = { ...image..}; ) that a secondary driver we get a pointer to and then download this firmware to my adapter (adapter DMAs the firmware from the physical address I pass it). Currently I have the secondary driver allocate a contiguous memory segment and copy the image into that segment. I would like to avoid this if possible. Is it safe to simply allocate an IOMemoryDescriptor with a pointer to the image and the images length then call getPhysicalSegment to get the start of next segment I want the adapter to download (I have to DMA in chunks smaller then the whole firmware image). I think I know the answer but I keep swapping between working on different OSes (Window NT/2000, Solaris, Mac OS, and Mac OS X) and it becomes hard to keep things straight :{ .... so I thought I better ask to make sure.

1 0