June 2005 - Darwin-kernel - lists.apple.com

Re: System call to increase the heap size
by Terry Lambert 29 Jun '05

29 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com It's a little harder than that, since Darwin is based on Mach. You need to look in the right places: Use the web.mit.edu pages for Darwin reference, though... -- Terry On Jun 28, 2005, at 10:06 PM, Mohanasundaram Chandran wrote: Hi All, I am in the process of implementing a memory manager for Darwin.I Linux i used the sys_brk system call (not the user lever legacy POSIX brk function.). I would like to know what is the similar system call in Darwin. Can anybody help please? This email sent to tlambert(a)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.… http://developer.apple.com/documentation/Performance/Conceptual/ ManagingMemory/Articles/MemoryAlloc.html http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/ vm_allocate.html See also the source to the standard memory manager for Darwin, which is located in libc, e.g.: http://darwinsource.opendarwin.org/10.3/Libc-320/gen/ scalable_malloc.c I expect that if you are using code that's portable to GNU Herd, then you already support it, since that's also Mach-based: http://gd.tuwien.ac.at/gnu/gnudoc/machinfo-0.3/html_chapter/ mach_5.html Regards, Mohan. _______________________________________________ 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 site_archiver(a)lists.apple.com

1 0

System call to increase the heap size
by Mohanasundaram Chandran 29 Jun '05

29 Jun '05

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:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=F+3T7RDrcAuz6rkF1V+bAMA4cigLUG8dbFM8qWzzOpUthk5vSDbsEUmfxe5t0dh3qEb8so1IwIO4LjUEz0lI4fArSqp6Auq5TmTM75+11hk2Zvu1xHsk58rs5wFV1mH4PFdS7hUx3LdZOwC0/ikfyl/FH5Ba2FzgO5mHOOkVazA= Hi All, I am in the process of implementing a memory manager for Darwin.I Linux i used the sys_brk system call (not the user lever legacy POSIX brk function.). I would like to know what is the similar system call in Darwin. Can anybody help please? Regards, Mohan. _______________________________________________ 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: driver stacked on top of another driver
by Dean Reece 28 Jun '05

28 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Welcome to the Platform! Cheers, - Dean _______________________________________________ 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 Jun 28, 2005, at 01:56, santosh katvate wrote: I am new to mac os x driver development. I want to know whether we can stack a driver on top of other driver So that we will be able to trap all the read/write request. Yes, this is fairly straight forward. Whole disks, as well as partitions, are represented in IOKit by IOMedia objects. Each such object represents some number of bytes of persistent storage. All reads and writes to the underlying device (or partition) goes through these objects. You can insert IOMedia Filter objects between each of these objects and their clients such that the read & write requests go through your object. If you go to http://developer.apple.com and search for "IOMedia" and "Filter", you'll find several relevant documents. You'll wind up creating a kernel extension (KEXT) that contains a class which is a subclass of IOMedia. It will use IOKit matching to make sure it stacks on top of the IOMedia objects of interest, being careful that it doesn't match on itself or you'll end up with an infinite stack. This has been discussed on this forum as well as Darwin Drivers, so you may also want to search the archives. This email sent to site_archiver(a)lists.apple.com

1 0

Re: mbuf from scratch
by Justin C. Walker 28 Jun '05

28 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jun 28, 2005, at 15:07 , Josh Graessley wrote: Cheers, Justin -- Justin C. Walker, Curmudgeon-at-Large /~\ The ASCII \ / Ribbon Campaign X Help Cure HTML Email / \ _______________________________________________ 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 Jun 28, 2005, at 2:37 PM, Justin C. Walker wrote: [snip] As Justin noted, the rcvif is ignored for the outbound path, hence the name receive if. This will usually be NULL on the outbound path. If you go to inject a packet inbound, you will need to set the rcvif to something as well as fiddle with the packet to get it in the right state. Thanks, Josh. I had this concern in the back of my head that rcvif might be used on the outbound path for something other than the "interface the packet was received on" (something in ipsec code maybe). In any case, you (Carl) should preserve the value you find in the mbuf that you are going to copy, just to be on the safe side. I don't think that there is a timing problem lurking in there, but reviewing the kernel code in this area can't hurt. This email sent to site_archiver(a)lists.apple.com

1 0

RE: mbuf from scratch
by Carl Smith 28 Jun '05

28 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcV8Lcx+zAYNsd2TQE6O5SFg1BnzYAAArDvg Thread-topic: mbuf from scratch Great news Josh, this solves a few headaches for me. I appreciate your come back. Carl -----Original Message----- From: darwin-kernel-bounces+csmith=fortresstech.com(a)lists.apple.com [mailto:darwin-kernel-bounces+csmith=fortresstech.com@lists.apple.com] On Behalf Of Josh Graessley Sent: Tuesday, June 28, 2005 6:08 PM To: Darwin Kernel Subject: Re: mbuf from scratch On Jun 28, 2005, at 2:37 PM, Justin C. Walker wrote: > Thanks for enlarging on that idea. > > It's been a while since I looked deeply at the output path, but > there are a few things to consider here. Perhaps Josh can comment. > > I believe that, unless the destination is the loopback adapter > ("lo0"), rcvif on outbound packets is NULL; it is mostly used on > the input path. > > If it is used in a serious way on the outbound path, you should be > really careful about doing what you are doing. If there is an > "ifp" associated to the mbuf, and it is somehow pointing to the > outbound interface, a change in routing information that occurs > between the time you snag the original and the time that you inject > the munged mbuf might affect the proper value for that ifp. I > don't think this is the case, but you should try to verify it > (i.e., try to follow the ip_output code, as well as that for the > transport protocols :-}). > > This is just a note of caution; as I said, I don't think it's an > issue. Josh? As Justin noted, the rcvif is ignored for the outbound path, hence the name receive if. This will usually be NULL on the outbound path. If you go to inject a packet inbound, you will need to set the rcvif to something as well as fiddle with the packet to get it in the right state. -josh _______________________________________________ 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: mbuf from scratch
by Josh Graessley 28 Jun '05

28 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jun 28, 2005, at 2:37 PM, Justin C. Walker wrote: Thanks for enlarging on that idea. -josh _______________________________________________ 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 It's been a while since I looked deeply at the output path, but there are a few things to consider here. Perhaps Josh can comment. I believe that, unless the destination is the loopback adapter ("lo0"), rcvif on outbound packets is NULL; it is mostly used on the input path. If it is used in a serious way on the outbound path, you should be really careful about doing what you are doing. If there is an "ifp" associated to the mbuf, and it is somehow pointing to the outbound interface, a change in routing information that occurs between the time you snag the original and the time that you inject the munged mbuf might affect the proper value for that ifp. I don't think this is the case, but you should try to verify it (i.e., try to follow the ip_output code, as well as that for the transport protocols :-}). This is just a note of caution; as I said, I don't think it's an issue. Josh? As Justin noted, the rcvif is ignored for the outbound path, hence the name receive if. This will usually be NULL on the outbound path. If you go to inject a packet inbound, you will need to set the rcvif to something as well as fiddle with the packet to get it in the right state. smime.p7s

1 0

FW: mbuf from scratch
by Carl Smith 28 Jun '05

28 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcV8KciByvz4+jU3QOmCyXoLGyi0hQAAOKKgAAAmUEA= Thread-topic: mbuf from scratch Thanks Justin, I am not interested in the loopback interface, mostly the 'en' interfaces. "rcvif on outbound packets is NULL;" If that is true, then that would be or great relief to me. I'll do some checking/testing/printf stuff. :) I have looked at the ip_output, but now that you bring it up I will be more scrutinizing. Carl PS I would be interested in Josh's comments, also. :) -----Original Message----- From: darwin-kernel-bounces+csmith=fortresstech.com(a)lists.apple.com [mailto:darwin-kernel-bounces+csmith=fortresstech.com@lists.apple.com] On Behalf Of Justin C. Walker Sent: Tuesday, June 28, 2005 5:38 PM To: Darwin Kernel Subject: Re: mbuf from scratch On Jun 28, 2005, at 14:24 , Carl Smith wrote: > > Justin- > > Got it, guess I was just confused on the 'ifp' struct. > > Using the term 'create from scratch' was with idea that when I capture > the original mbuf I play around with it, i.e. the data, then send > it out > after I copy back 'my' data. In the mean time, other mbufs, might/will > be coming in to a pool, of mbufs, I have. Of course I keep the flow > all > linear, but I was just concerned with 'hanging' on to the 'ifp' as > other > mbufs backed up. But then I am not 'hanging' onto the original, my > pool > of mbufs, are 'copies' of the originals. Thanks for enlarging on that idea. It's been a while since I looked deeply at the output path, but there are a few things to consider here. Perhaps Josh can comment. I believe that, unless the destination is the loopback adapter ("lo0"), rcvif on outbound packets is NULL; it is mostly used on the input path. If it is used in a serious way on the outbound path, you should be really careful about doing what you are doing. If there is an "ifp" associated to the mbuf, and it is somehow pointing to the outbound interface, a change in routing information that occurs between the time you snag the original and the time that you inject the munged mbuf might affect the proper value for that ifp. I don't think this is the case, but you should try to verify it (i.e., try to follow the ip_output code, as well as that for the transport protocols :-}). This is just a note of caution; as I said, I don't think it's an issue. Josh? Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- Men are from Earth. Women are from Earth. Deal with it. -------- _______________________________________________ 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/csmith%40fortresste ch.com This email sent to csmith(a)fortresstech.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: mbuf from scratch
by Justin C. Walker 28 Jun '05

28 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jun 28, 2005, at 14:24 , Carl Smith wrote: Justin- Got it, guess I was just confused on the 'ifp' struct. Thanks for enlarging on that idea. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- Men are from Earth. Women are from Earth. Deal with it. -------- _______________________________________________ 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.… Using the term 'create from scratch' was with idea that when I capture the original mbuf I play around with it, i.e. the data, then send it out after I copy back 'my' data. In the mean time, other mbufs, might/will be coming in to a pool, of mbufs, I have. Of course I keep the flow all linear, but I was just concerned with 'hanging' on to the 'ifp' as other mbufs backed up. But then I am not 'hanging' onto the original, my pool of mbufs, are 'copies' of the originals. It's been a while since I looked deeply at the output path, but there are a few things to consider here. Perhaps Josh can comment. I believe that, unless the destination is the loopback adapter ("lo0"), rcvif on outbound packets is NULL; it is mostly used on the input path. If it is used in a serious way on the outbound path, you should be really careful about doing what you are doing. If there is an "ifp" associated to the mbuf, and it is somehow pointing to the outbound interface, a change in routing information that occurs between the time you snag the original and the time that you inject the munged mbuf might affect the proper value for that ifp. I don't think this is the case, but you should try to verify it (i.e., try to follow the ip_output code, as well as that for the transport protocols :-}). This is just a note of caution; as I said, I don't think it's an issue. Josh? This email sent to site_archiver(a)lists.apple.com

1 0

RE: mbuf from scratch
by Carl Smith 28 Jun '05

28 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcV8IyTTn+oBm+TsQb+Tu1EoaQwRuwAA4oaA Thread-topic: mbuf from scratch Justin- Got it, guess I was just confused on the 'ifp' struct. Using the term 'create from scratch' was with idea that when I capture the original mbuf I play around with it, i.e. the data, then send it out after I copy back 'my' data. In the mean time, other mbufs, might/will be coming in to a pool, of mbufs, I have. Of course I keep the flow all linear, but I was just concerned with 'hanging' on to the 'ifp' as other mbufs backed up. But then I am not 'hanging' onto the original, my pool of mbufs, are 'copies' of the originals. Carl -----Original Message----- From: darwin-kernel-bounces+csmith=fortresstech.com(a)lists.apple.com [mailto:darwin-kernel-bounces+csmith=fortresstech.com@lists.apple.com] On Behalf Of Justin C. Walker Sent: Tuesday, June 28, 2005 4:52 PM To: Darwin Kernel Subject: Re: mbuf from scratch On Jun 28, 2005, at 13:16 , Carl Smith wrote: > I was trying to get the consensus, is it OK to keep this "copied" > 'ifp' > around or should I create everything 'new' from scratch, when > inputting > my data into the mbuf? I am asking this question relating to > performance, timing, memory and potential errors. Is there any benefit > to creating the 'ifp' from scratch versus keeping a copy around? The 'ifp' is a pointer to a kernel structure that you have no control over. It is associated with a given mbuf at some point during the mbuf's passage through the twisty little code passages in the kernel. Therefore, - if you are 'duplicating' an mbuf, copy the value from the original mbuf and store it in the new one (e.g., as an argument to m_devget()). - do *not* save it anywhere for later use. The fact that you keep referring to creating the ifp from scratch concerns me (i.e., I don't understand what you are getting at). You never create this pointer; you just copy it from the original mbuf to the copy. What are you thinking about that makes "create from scratch" a meaningful operation? Regards, Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- If you're not confused, You're not paying attention -------- _______________________________________________ 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/csmith%40fortresste ch.com This email sent to csmith(a)fortresstech.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: mbuf from scratch
by Justin C. Walker 28 Jun '05

28 Jun '05

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jun 28, 2005, at 13:16 , Carl Smith wrote: Regards, Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- If you're not confused, You're not paying attention -------- _______________________________________________ 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 was trying to get the consensus, is it OK to keep this "copied" 'ifp' around or should I create everything 'new' from scratch, when inputting my data into the mbuf? I am asking this question relating to performance, timing, memory and potential errors. Is there any benefit to creating the 'ifp' from scratch versus keeping a copy around? The 'ifp' is a pointer to a kernel structure that you have no control over. It is associated with a given mbuf at some point during the mbuf's passage through the twisty little code passages in the kernel. Therefore, - if you are 'duplicating' an mbuf, copy the value from the original mbuf and store it in the new one (e.g., as an argument to m_devget()). - do *not* save it anywhere for later use. The fact that you keep referring to creating the ifp from scratch concerns me (i.e., I don't understand what you are getting at). You never create this pointer; you just copy it from the original mbuf to the copy. What are you thinking about that makes "create from scratch" a meaningful operation? This email sent to site_archiver(a)lists.apple.com

1 0