December 2006 - Darwin-kernel

Re: mbuf_outbound_finalize bug?
by Bhavesh Davda 29 Dec '06

29 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=m1FTIZZGWE1cpj7kSPgIkmFO0w9SfBgDduDmOtcQPTgYO60KTebrcV6+RklsjVz4ZTqA9Uj1fEzSVnqKnnEDa7UlONmdo7vgmWx63ivalD1R0zmurWc3oGfq27thX5xo/8HDITpyb73WfBdX6MmLAiLXDQOO3bEhmYD61WobNCQ= Hi Terry, That's exactly what I ended up implementing. I haven't read RFC 1624, but I will. Related question: if ever csum_flags has both CSUM_IP and CSUM_TCP | CSUM_UDP set, then what is csum_data going to point to? Thanks! - Bhavesh Are you changing the length of the packet, or only the contents? If you are only changing the contents, then I suggest an mbuf-chain aware incremental checksum update as an alternative to copying it to a contiguous buffer, operating on it, converting it to mbufs, then doing a full software checksum of the whole packet. See RFC 1624. -- Terry On Dec 22, 2006, at 10:12 AM, Adi Masputra wrote: > On Dec 22, 2006, at 9:58 AM, Bhavesh Davda wrote: >> >> I compare the result of mbuf_pkthdr_len agains the network-byte-order >> value of IP length on purpose, to know whether indeed the value of IP >> length in the packet is *not* in host-byte-order, as I thought you >> said mbuf_outbound_finalize() expects. > > Since your module is an interface filter, the field(s) in the > header(s) > will be in network byte-order. All you need to do is to byte-swap > the length at all times assuming it is an IPv4 packet. > >> >> Oh boy. This is going to get quite expensive to do on a per packet >> basis. I thought I could simply get a pointer into the packet payload >> to the IP length field in the IP header, and do a memory read/write, >> rather than going through so many function calls and memcpy's, albeit >> small (2 byte) ones. > > Well, you are already requesting the stack to perform software > checksum > calculation on the packet which includes the transport payload; in > terms > of per-byte cost that is much more significant than traversing the > mbuf > chain to safely obtain the 2-octets IP length in the header. :) > >> >> Is there any other way to do it more optimally? I understand your >> concern about non-linear mbufs, and not assuming that the IP header >> is >> in the pkthdr mbuf. But realistically, is that ever going to be the >> case? >> > > There's no guarantee that the headers will be in contiguous span > although for the majority of cases they would. Sorry, but as I said > the fix is already in order. > > Adi > >> Thanks! >> >> -- >> Bhavesh P. Davda > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com > > This email sent to tlambert(a)apple.com -- Bhavesh P. Davda _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 12/28/06, Terry Lambert <tlambert(a)apple.com> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Re: mbuf_outbound_finalize bug?
by Terry Lambert 29 Dec '06

29 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Are you changing the length of the packet, or only the contents? See RFC 1624. -- Terry I compare the result of mbuf_pkthdr_len agains the network-byte-order value of IP length on purpose, to know whether indeed the value of IP length in the packet is *not* in host-byte-order, as I thought you said mbuf_outbound_finalize() expects. Oh boy. This is going to get quite expensive to do on a per packet basis. I thought I could simply get a pointer into the packet payload to the IP length field in the IP header, and do a memory read/write, rather than going through so many function calls and memcpy's, albeit small (2 byte) ones. There's no guarantee that the headers will be in contiguous span although for the majority of cases they would. Sorry, but as I said the fix is already in order. Adi Thanks! -- Bhavesh P. Davda _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… If you are only changing the contents, then I suggest an mbuf-chain aware incremental checksum update as an alternative to copying it to a contiguous buffer, operating on it, converting it to mbufs, then doing a full software checksum of the whole packet. On Dec 22, 2006, at 10:12 AM, Adi Masputra wrote: On Dec 22, 2006, at 9:58 AM, Bhavesh Davda wrote: Since your module is an interface filter, the field(s) in the header(s) will be in network byte-order. All you need to do is to byte-swap the length at all times assuming it is an IPv4 packet. Well, you are already requesting the stack to perform software checksum calculation on the packet which includes the transport payload; in terms of per-byte cost that is much more significant than traversing the mbuf chain to safely obtain the 2-octets IP length in the header. :) Is there any other way to do it more optimally? I understand your concern about non-linear mbufs, and not assuming that the IP header is in the pkthdr mbuf. But realistically, is that ever going to be the case? This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Strange boot problem!!
by Ravi 28 Dec '06

28 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com While booting my system I get a kernel panic saying :- Unable to find driver for this platform : ACPI Thanks _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Tried doing an upgrade, so inserted the installation CD at boot time, but it just doesnt gets into installation and keeps entering the panic state. Tried Command+S single user mode but nothing changed. Is there a key combination to fix this? How can I upgrade my OS in this situation without loosing the data, using the installation CD? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Finding Kernel Extension Developers
by Peter Lovell 27 Dec '06

27 Dec '06

site_archiver(a)lists.apple.com Delivered-To: Darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Notification of fork()
by Curtis Jones 27 Dec '06

27 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S5otGxUGwmzHhyo/eb6hUofF1ktQxCDbBjH+kmDRin24E1/w5CtVIE+/fSQ9TJWQ36Fhe055nolWui/gGWRjHCF5R48u/5pGZWfK32FPmLFCv0bUbrHW/MDISksfx3w+WDmi+ahkPpv/5jOwdmSuEDu0LFVPP0LUGCfbfBKb+Ow= I was looking at kevent. In userspace, the NOTE_FORK event seems to be pretty close to what I'm looking for. Any idea if it (or similar) can be accessed from the kext? -- Curtis Jones _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Notification of fork()
by Curtis Jones 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DQJ4MgnDKzQqWyWsrEjdQv6by/gJ4cUEu9LjgU52EOSpC+FKCWrXM5bhYEoQ5qov40eQ1vHIYVoyaJGnkzyjXzF326Vk/W5hH2FAyKSZi9Otv4ZqpCrXOErIhNE96iEK5G4OgKqK9V0D31N0vrf2tl6XelCWFxMieyL/92trkzA= I tried to parse your original description, but was unable to deduce what you're actually trying to do. Are you attempting to determine the identity of the originator of the incoming connection, or the party that will ultimately call accept(2)? Is there any reason why you have to know early, rather than waiting until the connection is accepted before determining whether or not to block it? This is for purposes of approval. Outgoing connections are a walk-in-the-park in comparison. When an incoming connection is, um, coming in, to a listener to which my socket filter is attached, the connect() callback is called for the listener socket. Based on the return value from that callback, the new incoming connection will be allowed/denied. This decision is based off the endpoint information for the socket and the associated process information. I have not tried to close a socket that my kext did not explicitly open, but assuming that I could, then I could perhaps postpone the decision by preventing any data send/recv until the pid was known for the new socket. Without being aware of fork()'s, I wouldn't always know the path-to-executable, but knowing the correct pid is ... something. So, to plainly answer your question: I'd like to know both the remote endpoint and the party (ie, the pid that called accept(), and the pid that started the listener (so that I can know the name of the executable)) that called accept(). The project is this: http://glowworm.us -- Curtis Jones _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 12/26/06, Michael Smith <drivers(a)mu.org> wrote: This email sent to site_archiver(a)lists.apple.com

1 0

Re: implementing an AudioIOFunction
by Josh Rodatus 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com ~ Josh On Dec 26, 2006, at 3:09 PM, Kevin Elliott wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Thank you all for your help. I think you've got me on the right track now. At 11:18 -0500 on 12/26/06, Josh Rodatus wrote: How often are you writing to the socket and ow much data are you writing? My first guess would be that your writing so often that the constants calls out to the driver is causing the system to stutter. I'm writing 2048 bytes of data every time the audio stream calls my AudioIOFunction >function, about every 1/100 of a second. My gut reaction is that that sounds like an awful lot of bouncing back and forth between the kernel and user space. One simple thing to try would be reducing the frequency of your writes- queue the data up and do larger writes. Someone suggested a shared ring buffer, and I can see some very attractive advantages in that. It sounds like your just doing display, which means you don't _really_ care how accurate the data in the buffer is. If latency is becoming an issue, your much rather lose data and hope to sync up in the future rather than try to stay to synchronized. It sounds like you could basically get away with almost no "communication" between kernel and user space. Basically your app hands the kernel a memory buffer, the kernel writes data into it, and your app reads data out of it. If the kernel gets ahead of you, you lose data in the buffer- but you didn't want that data anyway, since it's old data. Just to share credit, this technique is similar to how isochronous transfers are handled by FireWire. -- ______________________________________________________ Arguing with an engineer is like wrestling with a pig in mud. After a while, you realize the pig is enjoying it. ______________________________________________________ Kevin Elliott <mailto:kelliott@mac.com> AIM/iChatAV: kelliott(a)mac.com (video chat available) ______________________________________________________ This email sent to site_archiver(a)lists.apple.com

1 0

Re: Notification of fork()
by Michael Smith 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Dec 26, 2006, at 11:50 AM, Curtis Jones wrote: So, even if the incoming connection does not have a pid associated with it (at the time that I need to know the pid), I do know the associated local port, and I can look at the existing listeners and find the one that corresponds, and I know the pid that created the listener (even if it is not the one that is calling accept). So, in some cases I'll have the correct pid/path, and in other cases I'll have just one value or neither. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I tried to parse your original description, but was unable to deduce what you're actually trying to do. Are you attempting to determine the identity of the originator of the incoming connection, or the party that will ultimately call accept(2)? Is there any reason why you have to know early, rather than waiting until the connection is accepted before determining whether or not to block it? This email sent to site_archiver(a)lists.apple.com

1 0

Re: implementing an AudioIOFunction
by Kevin Elliott 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com At 11:18 -0500 on 12/26/06, Josh Rodatus wrote: How often are you writing to the socket and ow much data are you writing? My first guess would be that your writing so often that the constants calls out to the driver is causing the system to stutter. I'm writing 2048 bytes of data every time the audio stream calls my AudioIOFunction >function, about every 1/100 of a second. My gut reaction is that that sounds like an awful lot of bouncing back and forth between the kernel and user space. One simple thing to try would be reducing the frequency of your writes- queue the data up and do larger writes. Someone suggested a shared ring buffer, and I can see some very attractive advantages in that. It sounds like your just doing display, which means you don't _really_ care how accurate the data in the buffer is. If latency is becoming an issue, your much rather lose data and hope to sync up in the future rather than try to stay to synchronized. It sounds like you could basically get away with almost no "communication" between kernel and user space. Basically your app hands the kernel a memory buffer, the kernel writes data into it, and your app reads data out of it. If the kernel gets ahead of you, you lose data in the buffer- but you didn't want that data anyway, since it's old data. Just to share credit, this technique is similar to how isochronous transfers are handled by FireWire. -- ______________________________________________________ Arguing with an engineer is like wrestling with a pig in mud. After a while, you realize the pig is enjoying it. ______________________________________________________ Kevin Elliott <mailto:kelliott@mac.com> AIM/iChatAV: kelliott(a)mac.com (video chat available) ______________________________________________________ _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Notification of fork()
by Curtis Jones 26 Dec '06

26 Dec '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h6GlEnhHdUY09808ntnSlKrON7GYj3zk+xmFdbQsbV4IsWaDR5JMWIJx9mrFAbdIia9ShwtDh4Ru9yzzBwJfukFeGj+Mvq+y2HsLPE+QEm3EI5oNwam2axYFk0jbcC9ynvodhZp+hlAA34+CoBOzsrE9LdoqIpteHy0EGz9fGAs= The kernel's "permanent memory" is completely full of bits of the kernel, so wherever it might go that ain't it. After looking into it some more, I was going to try to avoid that approach anyway. It looks promising, but also not so much a viable short-term solution. So, even if the incoming connection does not have a pid associated with it (at the time that I need to know the pid), I do know the associated local port, and I can look at the existing listeners and find the one that corresponds, and I know the pid that created the listener (even if it is not the one that is calling accept). So, in some cases I'll have the correct pid/path, and in other cases I'll have just one value or neither. Not ideal, but it'll have to do until I can find a way to know about fork()'ing activity. -- Curtis Jones _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On 12/26/06, Michael Smith <drivers(a)mu.org> wrote: This email sent to site_archiver(a)lists.apple.com

1 0