September 2006 - Darwin-kernel

Networking: mbuf->m_hdr.mh_data doesn't include DLIL header?
by Bhavesh Davda 18 Sep '06

18 Sep '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:mime-version:content-type:content-transfer-encoding:content-disposition; b=rN1EiVWPUTCGC81bPsoS6U7koF74fELc5HpYuvAbY/+zTAGrxq1HCg/iPD9HRae3S7CJjRC0pB1+vkWYEsW7tXsbqDSYKPSOdKwhfXaoMIuIXEZVy8L2Pfe7Ea/6raDiRTq5m8LhFryS4Ch3rkpJXBztkWnJm8t+fnVfaMlPv48= For certain packets that my iff_input_func is receiving, when I looked at the entire mbuf structure received in parameter 4, I noticed that the m_hdr.mh_data field offsets 14 bytes beyond the start of the ethernet frame. This is causing my mbuf_dup() cloned mbuf to not contain the 14 bytes of ethernet header in my NKE. Looking in the original mbuf received in my iff_input_func, the 14 bytes of ethernet header are in the mbuf body at mbuf->M_dat.MH.MH_dat.MH_databuf[0..13]. What am I doing wrong? How do I clone the mbuf to include the DLIL header? Thanks! - Bhavesh -- 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.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: question about mixed c/c++/obj c application:
by Travis Rose 17 Sep '06

17 Sep '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

question about mixed c/c++/obj c application:
by Travis Rose 17 Sep '06

17 Sep '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

question about socreate, soalloc and wait/nowait
by Peter Lovell 15 Sep '06

15 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hi folks, in working through a problem, I've become quite puzzled by the wait/ nowait characteristics of soalloc and socreate. Hopefully someone can enlighten me. The code is in xnu-792.6.76/bsd/kern/uipc_socket.c and there are three routines of interest:- socreate, soalloc and cached_sock_alloc. They're all near the start of the file. First puzzle is in socreate. At line 446 we have so = soalloc(p != 0, dom, type); and the first argument is whether or not it's OK to wait (i.e. block) for the allocation. But this will always be true since p is guaranteed to be non-NULL, having been fetched back at line 420 struct proc *p = current_proc(); The implementation of current_proc() guarantees to never return NULL. The code, in bsd_stubs.c, looks as though it may previously have returned NULL for kernel processes. Now, in the case where it might have returned NULL, it instead returns "kernproc" which points to proc0 structure. This characteristic goes all the way back to OS X 10.0. So I suspect that the socreate code was prepared to wait if current_proc () was on behalf of a user process but not for a kernel task. This is just speculation though -- as it is today it will always allow waiting. The archetypical code in Stevens vol.2 does a wait-style allocation, as does the current FreeBSD code. The second puzzle is in the "soalloc" routine. Its signature is struct socket * soalloc(waitok, dom, type) int waitok; int dom; int type; There is a comment there also which says ... * We don't implement `waitok' yet (see comments in uipc_domain.c). but I don't see any appropriate comments in that file. So, soalloc passes waitok to cached_sock_alloc, or else does a wait- style allocation itself. cached_sock_alloc does appear to treat waitok as true/false -- this code is around line 262 if (waitok) *so = (struct socket *) zalloc(so_cache_zone); else *so = (struct socket *) zalloc_noblock(so_cache_zone); However, there's one other reference to soalloc which suggests that the sense may be different. So, here are my questions ... 1. is there some reason for the "p != 0" usage in socreate? There are a couple of places this occurs. 2. what is the correct definition for "waitok" in soalloc? 3. should the soaloc call in sonewconn be wait-style or nowait? Thanks.....Peter _______________________________________________ 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 asked this question on another list but hadn't received any info, so thought I'd try here for wider distribution. The routine does not make use of "waitok" and there's no definition for it, such as whether it's true/false, or flags such as M_WAITOK/M_NOWAIT, or whatever. However, soalloc does pass it on a call. The code is (in part) if ((dom == PF_INET) && (type == SOCK_STREAM)) cached_sock_alloc(&so, waitok); else { MALLOC_ZONE(so, struct socket *, sizeof(*so), socket_zone, M_WAITOK); if (so) bzero(so, sizeof *so); } The implementation of sonewconn (actually done in sonewconn_internal, look at file upic_socket2.c line 345) explicitly passes "1" as the "waitok" argument to soalloc ... so = soalloc(1, head->so_proto->pr_domain->dom_family, head- >so_type); This usage is quite clearly a no-wait call both in Stevens and FreeBSD code. The original Mac OS X 10.0 release (xnu-123.5) had this argument as "0" but it had changed to "1" by the time of Mac OS X 10.1 (xnu-201). This email sent to site_archiver(a)lists.apple.com

1 0

Re: sock_receive() returning error as EINVAL
by Quinn 15 Sep '06

15 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I am writing a kernel mode driver for a modem.I am using TCP implementation for the same. The API sock_receive() and sock_receivembuf() are both returning error no 22 i.e EINVAL (Invalid argument).Can anyone please tell me the reason for the same.. I am attaching the code below for reference.. o In the simplest case, you can just pass NULL to msg. o msg_iov is ignored. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware _______________________________________________ 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.… At 6:36 +0100 11/9/06, sanjay yaragatti wrote: [Please don't cross post to mailing lists. As I'm not a member of darwin-drivers, I have no idea whether you got an answer on that mailing list, so I could be wasting my time be writing the following. And I kinda hate the thought that I'm wasting my time )-: ] Did you read the header doc comments in <sys/kpi_socket.h>? There are certain key statements that you seem to be ignoring. For example: o On entry, *recvlen is "Maximum number of bytes to receive in the mbuf chain.", and you've set it to zero. Finally, my reading of your email indicates that you're receiving from a TCP socket. If so, you don't need to ask for the sender of the data (that is, fill out msg_name and msg_namelen); it's going to be the same as the person you connected to. This email sent to site_archiver(a)lists.apple.com

1 0

RE: VFS write operations (Michael Welch)
by Michael Welch 14 Sep '06

14 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thread-index: AcbW5yy4sBQK4/3+SdGbJpoyTdqYuwBTdj1Q Thread-topic: VFS write operations (Michael Welch) Doh! I hadn't implemented VNOP_FSYNC. A simple "return 0;" implementation was enough to cure TextEdit's problems. Thanks! - Mike > -----Original Message----- > From: Sam Vaughan [mailto:sjv@sgi.com] > Sent: Tuesday, September 12, 2006 8:48 PM > To: Michael Welch > Cc: darwin-kernel(a)lists.apple.com > Subject: Re: VFS write operations (Michael Welch) > > On 13/09/2006, at 12:42 PM, Michael Welch wrote: > > > Thanks, Sam. I will give ktrace a whirl and see if > anything else pops > > up. In the mean time, I should mention: > > > > 1) I have not implemented VNOP_EXCHANGE. In VFS_GETATTR I > set it as a > > valid but not supported capability. "I'm aware of > ExchangeData, but I > > don't do that..." > > > > 2) I have implemented VNOP_RENAME, and it seems to work > fine from both > > the command line ($mv file1 file2) and through the Finder. > > > > In my TextEdit scenario, I don't even see a rename > attempted. I see > > it create a new file, write the contents there (successfully), read > > the file's attributes, and then delete it and bail. Maybe > ktrace will > > reveal some additional steps going on in there that I don't see > > otherwise. > > That's interesting. In the ktrace I just ran on UFS there's > very little happening between the first data write and the rename: > > 15177 TextEdit CALL open(0xbfffd560,0xa02,0x180) > 15177 TextEdit NAMI "/Volumes/ufs/.dat3b49.000" > 15177 TextEdit NAMI "._.dat3b49.000" > 15177 TextEdit RET open 7 > 15177 TextEdit CALL write(0x7,0x311320,0x5) > 15177 TextEdit GIO fd 7 wrote 5 bytes > "food > " > 15177 TextEdit RET write 5 > 15177 TextEdit CALL fsync(0x7) > 15177 TextEdit RET fsync 0 > 15177 TextEdit CALL close(0x7) > 15177 TextEdit RET close 0 > 15177 TextEdit CALL rename(0xbfffd560,0xbfffdda0) > 15177 TextEdit NAMI "/Volumes/ufs/.dat3b49.000" > 15177 TextEdit NAMI "/Volumes/ufs/.15177-179803682-1.txt" > 15177 TextEdit NAMI "._.dat3b49.000" > 15177 TextEdit NAMI "._.15177-179803682-1.txt" > 15177 TextEdit RET rename 0 > > Have you implemented VNOP_FSYNC? Perhaps the fsync call is > returning an error on your file system. > > Sam > _______________________________________________ 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: dumping the reservation
by Bill Angell 14 Sep '06

14 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Shaun, Bill _______________________________________________ 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.… Is there a definitive spec for what to do about dumping the ldarx/lwarx reservation on G5 vs G3/G4? I've seen code written four different ways: [1] my default which was to always dump it to -8(SP) regardless of CPU type, [2] dump it on G5 only, [3] store the same data back to the same address, or [4] leave it pending (ignore without storing) and continue. The best thing is to dump it into a cache line that you know is not being used by any other processor, so your default of using the stack should work fine. I haven't heard of any reason (correctness, performance, etc.) to conditionalize it based on processor type. Both the kernel and the user space code use that method almost exclusively (there are a few special-cased exceptions). Reservations should never be left dangling. It prevents future unpaired stwcx. instructions from unexpectedly succeeding and avoids any potential processor-specific issues as well. My bias has always been against storing back into the same data. It will steal the cache line from the processor that is using it, causing extra bus traffic to get it back. Also, if the other guy has reserved the memory, it just doesn't seem right for me to be storing into it, even if it is the same stuff... This email sent to site_archiver(a)lists.apple.com

1 0

dumping the reservation
by Shaun Wexler 14 Sep '06

14 Sep '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.… Is there a definitive spec for what to do about dumping the ldarx/ lwarx reservation on G5 vs G3/G4? I've seen code written four different ways: [1] my default which was to always dump it to -8(SP) regardless of CPU type, [2] dump it on G5 only, [3] store the same data back to the same address, or [4] leave it pending (ignore without storing) and continue. Now that I've rewritten all my asm with __LP64__ versions, I'm tempted to leave the ILP32 version optimized for G4 but want to know what type of pipeline flush or whatever I'd be causing on the G5 in doing so. Note that I have mainly G4-UP and an increasing number of i386-MP users, so G3/G5-UP,MP/i386-UP aren't as much of a concern in this case. -- Shaun Wexler MacFOH http://www.macfoh.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Manual sleep vs automatic sleep
by Ethan Bold 13 Sep '06

13 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Hello- Instead call: IOService::PMinit() IOService::joinPMtree() IOService::registerPowerDriver() And you can receive your sleep/wake notifications by overriding: IOService::setPowerState() http://darwinsource.opendarwin.org/Current/IOPCIFamily-34/IOPCIDevice.cpp static IOPMPowerState powerStates[ kIOPCIDevicePowerStateCount ] = { { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }, { 1, 0, IOPMPowerOn, IOPMPowerOn, 0, 0, 0, 0, 0, 0, 0, 0 } }; -Ethan On Sep 13, 2006, at 10:12 AM, rohit dhamija wrote: Hi All, // OReturn MyDriver::handlePowerEvent(void *target,void *refCon, UInt32 messageType,IOService *provider, void *messageArgument,vm_size_t argSize) { IOReturn err = kIOReturnUnsupported; MyDriver *tmpSntl = OSDynamicCast(MyDriver, (OSObject*)target); if(!tmpSntl) { DBLog(("\nMyDriver::handlePowerEvent, ERROR! provider invalid.\n")); return err; } switch (messageType) { case kIOMessageCanSystemSleep: break; case kIOMessageSystemWillSleep: MYLOGIC_FOR_SAVING_CONTEXT(); err = kIOReturnSuccess; break; case kIOMessageSystemWillNotSleep: break; default: err = kIOReturnUnsupported; break; } return(err); } Thanks and Regards, Rohit Dhamija -- Rohit Dhamija(M) 9818446545 _______________________________________________ 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/ebold%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.… This is not the optimal API-set to use to power manage your driver. For one thing, this API does not guarantee proper sleep/wake ordering between you and your provider. I just quickly googeld for "setPowerState" and found this IOPCIDevice.cpp example of signing up for power management. Your code will look very similar to that, except you only need two power states (0 == off; 1 == on): I have developed kext for my USB bulk device for Mac OS X 10.4.7 ppc G5/Intel. I need to save some context information before the system goes to sleep mode. The user can either do a manual sleep (going top left , click apple button and then sleep) or automatic sleep ( it will sleep as per the settings done in Energysaver ) Is there any difference b/w these two types of sleep ? Are there various types of sleep that we need to handle ? Below is the peice of code for handling sleep notification. But I am not sure if it will cater all types of sleep - sleep manual as well automatic. Please suggest. // register sleep notification _powerEventNotifier = registerPrioritySleepWakeInterest(MyDriver::handlePowerEvent,this); if (_powerEventNotifier) { retain(); This email sent to ebold(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Problems implementing write function of a character device
by Terry Lambert 13 Sep '06

13 Sep '06

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com I can't really improve on Mike's advice here. (2) The reason you are getting the 0 is that either: (b) the user is passing a 0 in their iov to a readv/writev call -- Terry On Sep 13, 2006, at 1:54 AM, sanjay yaragatti wrote: I am implementing write func for a character device. I am using the accessor methods uio_curriovlen(uio) and uio_curriovbase(uio) provided in the <sys/uio.h> file to get the length value of the current iovec associated with the given uio and the base address of the current iovec associated with the given uio respectively.However, both the calls are returning zero as the return value.Hence unable to copy the data from userspace to kernel space.Even tried using uiomove() inplace of copyin() but doesnt work. I have attached the code for reference.. Please let me know if something wrong in the code. ( dev_t device, struct uio *uio, int ioflag ) { INT ret = SUCCESS; INT is spelled "int". What is "PUCHAR"? Do you mean "unsigned char *"? If so, use it. UINT32 is spelled "uint32_t". user_size_t buff_len = 0, buff_base = 0; /* Get the minor number */ minor_num = minor(device); buff_len = uio_curriovlen(uio); buff_base = uio_curriovbase(uio); uio_curriovbase() returns user_addr_t not user_size_t. IOLog ("uio_curriovlen is %d & uio_curriovbase is %d\n ",buff_len,buff_base); tmp_buff = (PUCHAR) mem_alloc(buff_len); You should never, ever allocate memory on your hot path. For something like this, you would probably be fine with a buffer on the stack. if (NULL == tmp_buff) { IOLog("%s: Buffer is NULL\n", __FUNCTION__); return FAILURE; } if(ret = copyin(buff_base, tmp_buff,buff_len)!= 0) Why are you using copyin? Why aren't you updating the uio? Why aren't you checking whether the buffer is already in kernel space? How do you plan to deal with writev() calls that have more than one segment in the iovec? This is why you should use uiomove. { mem_free(tmp_buff,buff_len); IOlog("%s: Copy from user failed\n", __FUNCTION__); return FAILURE; } *(tmp_buff+ buff_len ) = 0; } And why don't you free the buffer in the success case? You're going to leak kernel memory here. Try something like #define WRITE_CHUNK_SIZE 128 int device_write(dev_t *dev, struct uio *uio, int ioflag) { char stk_buf[WRITE_CHUNK_SIZE]; int buf_len; /* check direction */ if (uio_rw(uio) != UIO_WRITE) return(EINVAL); /* loop bringing in chunks of data */ for (;;) { /* check UIO for more data */ buf_len = min(uio_resid(uio), WRITE_CHUNK_SIZE); if (buf_len == 0) break; /* bring in a chunk */ uiomove(stk_buf, buf_len, uio); /* emit chunk */ driver_emit_bytes(stk_buf, buf_len); } return(0); } Note that this as it stands is not very efficient; depending on your device you may want to bring in much larger chunks, or if you have a buffer pool for outbound data you might want to grab buffers in the uiomove loop and move into them rather than into a temporary stack buffer. If your device is fairly slow, however, this will work fine. You would not want to increase WRITE_CHUNK_SIZE to much more than 1KB or so, depending on how much stack you use elsewhere in your driver. With buffers that large you're looking at a higher- performance design though and mapping directly will start to be more attractive. = Mike --- Terry Lambert <tlambert(a)apple.com> wrote: Hi all, I am writing a kernel driver.I have as character device. I am unable to implement the device write method (dev_write( dev_t device, uio *uio, int ioflag)) since I don't know how to retrieve the buffer from struct uio. However on trying to dereference uio as uio->uio_iov->iov_base gave a compilation error. You may want to read /usr/include/sys/uio.h... /* * uio_curriovbase - return the base address of the current iovec associated * with the given uio_t. May return 0. */ user_addr_t uio_curriovbase( uio_t a_uio ); You can also look at the kernel sources; in this case, the function is implemented in: -- Terry __________________________________________________________ Yahoo! India Answers: Share what you know. Learn something new http://in.answers.yahoo.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/drivers%40mu.org _______________________________________________ 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.… As exposition, the reason uio structures have accessors and mutators instead of letting you access them directly is twofold: (1) It protects your driver from needing to know about 32 vs. 64 bit user space programs (a) you are failing to iterate the iov's from user space, and never get past the first one In any case, you should be using uiomove() in order to move the data, not doing it yourself. On Sep 13, 2006, at 8:45 AM, Michael Smith wrote: INT32 device_write Assuming this function is d_write in your cdevsw, it is read_write_fcn_t, which returns int, not "INT32". PUCHAR tmp_buff = NULL; UINT32 minor_num; On Sep 12, 2006, at 2:13 AM, sanjay yaragatti wrote: regestered it struct Is there a KPI to retrieve the buffer sent from user space? <http://www.opensource.apple.com/darwinsource/10.4.7.ppc/xnu-792.6.76/bsd/ke… This email sent to drivers(a)mu.org This email sent to site_archiver(a)lists.apple.com

1 0