July 2008 - Darwin-kernel - lists.apple.com

Real time question
by Andrea Di Pasquale 24 Jul '08

24 Jul '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version :content-transfer-encoding:message-id:content-type:to:from:subject :date:x-mailer; bh=ehNaDJq+v/CgRLYH5uQvusdTNUd8sSL9wMrOk9cT4TE=; b=A7kp8B/anTPWRztT8XPim2LpeGhF9CqqrvtmIXOa9hahYSp8uHdYXYFuxWyL3Ta5H0 zJbsmF8jvYeGvG/Eped5J8xQ6jobRwqFM/p3egiQY3JyTXDrCYFydMm1OekoFt/qpOr0 xihfc4P0133PoqyLXI+/BEINUl041T337ILQQ= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:content-transfer-encoding:message-id:content-type:to :from:subject:date:x-mailer; b=Y7WKlvPxY4lig5J15vi6Xlujm+lFsKi4X22txScwpc6xQDSy+Tnxjq1ar8pQQw0Fpa pEt1eTyXJeCN25UyqxSo2Oz9Qxdh5AupYAdweEwuqi3ioHgdC8okQrG8kckTiVELGwIA vwizvZcautQae3iBkjQE+3+yLJGuEThHmEEEo= Hi! Sorry, i'm not native english language. I'm Andrea, i'm student in secondary high school in Catania, Italy. I want to study real time and networking meccanysm in xnu kernel. Quinn wrote: --- "Real time" means lots of different things to lots of different people. I would not consider Mac OS X to be a real time operating system. However, that does not prevent it from solving numerous real time problems (for example, movie playback). If you can explain what you mean by "real time", we should be able to point you in the right direction. --- So, does networking works with real time meccanysm? Best regards, Andrea _______________________________________________ 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: Computer not shutting down
by mm w 24 Jul '08

24 Jul '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=kdOYpD86Ar2ThMiaFzFZmsWVTFIe86WKjfybxDXNlaM=; b=SAtIHZx/rpUTiNLJIu7BDN1YLO3jpukHPO9qaqqSIoJ4Y96y3VjgSMwf8f0rmrAy62 bC4HbKLT1JoQusT7NSC2Zhd3hXBfphyCXvwybQj6vzujs70LtB9GZ9QVQ5DITmqvrBkN nzb4CxhUXDgJ6k2/WlTwsW/MgcJfmK7cR8Ke8= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=UBpaLspLODxapWgftBz3DneR4ZTvowzYEw5ENkkEPuwEdUSJlVMpbirtDqMb/uqGEo S7Gla3QhW2HUUC/8FToujgf3Ntp2kYyX2lRjvIbQ6QfTRmZdUnt12MlDKoYZnfUaHrjZ 1FZgUEzCFIV/YlFhi3E535eHXBKQkQVx8dqOY= Yes sure, you solved temporary the problem, but you asked for advices regarding a good or a bad use of kernel API, you also complained about the lack of documentation, this was not fair, you could met the same problem in FB kernel and if you ask the same thing on FB mailing list you 'll get the same answers and maybe less political there's a implicit rule: as far as possible (it depends nke, fs) - do not use a method enclosed in a PRIVATE defined - you have to "considare" the rest of kernel APIs as protected // no need advertising - in MacOS IOKit is the public IO interface, kpis are also a public interface to the "bsd-like" API one of mistake of the previous kteam has been to expose mach primitives without warnings, and Terry try to correct this in 90% of his answers IMHO so what I try to express is: you asked for an advice despite your solved problem, "maybe" there is a alternative safer way to get your result, and "maybe" a better design, we can only express some theories, because you are not very "locace" about your entire app/model Cheers! On Thu, Jul 24, 2008 at 10:42 AM, Greg <greg(a)kinostudios.com> wrote: > > On Jul 24, 2008, at 1:32 PM, mm w wrote: > >> Hi Greg, maybe if you could describe a bit your mechanism, >> you could have a right answer and some leads >> for a example why do you need the "type" of a VNODE, >> - do you receive a userspace file event? > > > Well, the kext sends out file events, but I'm confused, I already solved my > problem (in the reply to myself), did you not see that? I simply needed a > vnode_put call after a vnode_lookup. > > - Greg > -- -mmw _______________________________________________ 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: Computer not shutting down
by Greg 24 Jul '08

24 Jul '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jul 24, 2008, at 1:32 PM, mm w wrote: Hi Greg, maybe if you could describe a bit your mechanism, you could have a right answer and some leads for a example why do you need the "type" of a VNODE, - do you receive a userspace file event? - Greg _______________________________________________ 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.… Well, the kext sends out file events, but I'm confused, I already solved my problem (in the reply to myself), did you not see that? I simply needed a vnode_put call after a vnode_lookup. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Computer not shutting down
by mm w 24 Jul '08

24 Jul '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=BpPLE89msZB2vd3ovpwKVLa0sdOQ8CqvoXbxg2K39BE=; b=CcGVzm7CcsoOXRFmgxcbsQH1QyOBiJ4+XTlxeMJfXomja+dtmKQGvXGbN4ld+6dtDz sDiZffzIzdzIegttDDXJ/iuSJGcyzBdykJnS/UvLPTw2at1e4InVYRDDGnk23q9vq91f AYHa0HMR+Ap6MO2hChaXdxkw5JrPHlVC+p1+M= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=rgSaRy/pLncydl2jlvDQQQxoIA+oFBY60nE+uRzXqlL+FsWT/sT0BgvjkjrzZEOQeC ufEsj/CXdX58HlndBvDW5JSTIvl2XfFzmO2gG/cpvNbROx8RF7nyDprN07kIS75JX4ae DQyRAj6ARagEhVJWFIgrrTBPKkkeaGP4HCpuI= Hi Greg, maybe if you could describe a bit your mechanism, you could have a right answer and some leads for a example why do you need the "type" of a VNODE, - do you receive a userspace file event? you 're only describing a small window, On Thu, Jul 24, 2008 at 9:41 AM, Greg <greg(a)kinostudios.com> wrote: > > On Jul 24, 2008, at 1:16 AM, Terry Lambert wrote: > >> The command is "showallstacks". It won't exist unless you load the >> "kgmacros" package into gdb > > Ah, thank you, and I apologize for not remembering that one. I've been > going down a TODO list for my project and this one brought me back to the > kernel side of it, something that I hadn't touched in a while... > >> The function is not provided for that purpose; the original purpose of the >> function being provided was to allow a mount point relookup and verification >> by vnode pointer for network file system clients to support mount -u. It is >> also internally used to obtain a vnode pointer that is held persistently for >> a long time when implementing shadow directories for support extended >> attributes on file systems that do not support them natively. >> >> In general, if you search the mailing list archives, you are going to find >> a large number of posts explaining why kernel level file I/O is an >> incredibly bad idea. Most of the related posts will tell you how to better >> do what it is you are trying to do. > > All I'm using it for is to determine whether a given path represents a > directory or not, after which I immediately dispose of the vnode_t. This > code runs infrequently as well, so hopefully this shouldn't be a "bad" use > of the vnode API? > > - Greg > _______________________________________________ > 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/openspecies%40gmail.com > > This email sent to openspecies(a)gmail.com > -- -mmw _______________________________________________ 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: Computer not shutting down
by Greg 24 Jul '08

24 Jul '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jul 24, 2008, at 1:22 PM, Michael Smith wrote: - Greg _______________________________________________ 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.… It's a bad use. What prevents the answer from changing between when you ask the question and when you use the information for some other purpose? It is very unlikely that the folder will change, or disappear, while the kernel is "using" it, and even if it does, the situation will be handled properly and nothing will crash. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Computer not shutting down
by Greg 24 Jul '08

24 Jul '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jul 24, 2008, at 1:16 AM, Terry Lambert wrote: - Greg _______________________________________________ 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.… The command is "showallstacks". It won't exist unless you load the "kgmacros" package into gdb Ah, thank you, and I apologize for not remembering that one. I've been going down a TODO list for my project and this one brought me back to the kernel side of it, something that I hadn't touched in a while... The function is not provided for that purpose; the original purpose of the function being provided was to allow a mount point relookup and verification by vnode pointer for network file system clients to support mount -u. It is also internally used to obtain a vnode pointer that is held persistently for a long time when implementing shadow directories for support extended attributes on file systems that do not support them natively. In general, if you search the mailing list archives, you are going to find a large number of posts explaining why kernel level file I/O is an incredibly bad idea. Most of the related posts will tell you how to better do what it is you are trying to do. All I'm using it for is to determine whether a given path represents a directory or not, after which I immediately dispose of the vnode_t. This code runs infrequently as well, so hopefully this shouldn't be a "bad" use of the vnode API? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Real Time question
by Quinn 24 Jul '08

24 Jul '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com 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 14:11 +0200 23/7/08, Andrea Di Pasquale wrote: I'm reading than mac os x supported real time meccanysm through Mach, is it true? "Real time" means lots of different things to lots of different people. I would not consider Mac OS X to be a real time operating system. However, that does not prevent it from solving numerous real time problems (for example, movie playback). If you can explain what you mean by "real time", we should be able to point you in the right direction. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Computer not shutting down
by Terry Lambert 24 Jul '08

24 Jul '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com ... -- Terry _______________________________________________ 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 Jul 23, 2008, at 6:22 PM, Greg wrote: On Jul 23, 2008, at 8:47 PM, Terry Lambert wrote: If you had NMI'ed the machine and done two machine debugging, it would have been clear from the stack traces you posted that the unmount was blocked by the vnode being held on the device. I did do this, however I wasn't able to get any stack trace, and therefore wasn't able to post it to the list. It just hanged on "continuing", and entering debug mode just showed me the stack trace for the debug-mode thing itself. Perhaps I could have played around with GDB more, but at the time it had not occurred to me to try to jump to other threads (and I did not remember the commands to do that..) The command is "showallstacks". It won't exist unless you load the "kgmacros" package into gdb, as described at: <http://developer.apple.com/documentation/Darwin/Conceptual/KEXTConcept/KEXT… > As to why vnode_lookup() is not well documented: we don't want you doing file I/O from your KEXT. It's fine to not want people to do file I/O from a KEXT, but if you're going to provide the functions for doing so, at least provide a note in the header along the lines of, "Use of these functions is strongly discouraged because ____. Use at your own risk." Otherwise, you might get people posting to the mailing list asking for help using them... and that's just annoying! ;-) The function is not provided for that purpose; the original purpose of the function being provided was to allow a mount point relookup and verification by vnode pointer for network file system clients to support mount -u. It is also internally used to obtain a vnode pointer that is held persistently for a long time when implementing shadow directories for support extended attributes on file systems that do not support them natively. In general, if you search the mailing list archives, you are going to find a large number of posts explaining why kernel level file I/O is an incredibly bad idea. Most of the related posts will tell you how to better do what it is you are trying to do. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Computer not shutting down
by Greg 24 Jul '08

24 Jul '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Jul 23, 2008, at 8:47 PM, Terry Lambert wrote: - Greg _______________________________________________ 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 had NMI'ed the machine and done two machine debugging, it would have been clear from the stack traces you posted that the unmount was blocked by the vnode being held on the device. I did do this, however I wasn't able to get any stack trace, and therefore wasn't able to post it to the list. It just hanged on "continuing", and entering debug mode just showed me the stack trace for the debug-mode thing itself. Perhaps I could have played around with GDB more, but at the time it had not occurred to me to try to jump to other threads (and I did not remember the commands to do that..) Similarly, if you had provided a cut down example that reproduced the problem, we could have done the same debugging on our own machines, and seen that the the unmount was being blocked by the vnode being held open on the device. I would have provided such a thing if I knew where to even begin looking to find one, I had no idea what was wrong. Short of that, there's a bazillion things that could have caused the issue, and without knowing what you were doing, it's rather unreasonable to expect someone to pull an answer like that out of thin air 17 hours after you posted last night, and about 8 hours after most of us got enough caffeine in us to be able to read your post. Terry, I really don't think what I said was that unreasonable.. please don't think that I'm under the impression that this mailing list exists for people to jump at my whim and fix all my problems. I realize that when I post here that I'm merely appealing to the kind nature in people, who, if they choose, can help answer one of my questions. I know that they do this at their own leaser and on their own time, and I do not expect anything more. When I posted my email it was out of desperation, hoping simply that someone on the list might know what is happening when the screen says "continuing". I did not know that a "bazillion things" happened at that moment, so I thought I'd ask just in case. A simple reply along those lines would have sufficed and I would have gone along my merry way poking in the dark. As to why vnode_lookup() is not well documented: we don't want you doing file I/O from your KEXT. It's fine to not want people to do file I/O from a KEXT, but if you're going to provide the functions for doing so, at least provide a note in the header along the lines of, "Use of these functions is strongly discouraged because ____. Use at your own risk." Otherwise, you might get people posting to the mailing list asking for help using them... and that's just annoying! ;-) This email sent to site_archiver(a)lists.apple.com

1 0

Re: Computer not shutting down
by Terry Lambert 24 Jul '08

24 Jul '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com This mailing list really isn't a support channel in the first place. -- Terry http://lists.apple.com/archives/darwin-kernel/2007/Jun/msg00111.html - Greg On Jul 22, 2008, at 11:10 PM, Greg wrote: continuing continuing done CPU halted Much appreciated, - Greg _______________________________________________ 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/greg%40kinostudios.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/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 had NMI'ed the machine and done two machine debugging, it would have been clear from the stack traces you posted that the unmount was blocked by the vnode being held on the device. Similarly, if you had provided a cut down example that reproduced the problem, we could have done the same debugging on our own machines, and seen that the the unmount was being blocked by the vnode being held open on the device. Short of that, there's a bazillion things that could have caused the issue, and without knowing what you were doing, it's rather unreasonable to expect someone to pull an answer like that out of thin air 17 hours after you posted last night, and about 8 hours after most of us got enough caffeine in us to be able to read your post. As to why vnode_lookup() is not well documented: we don't want you doing file I/O from your KEXT. On Jul 23, 2008, at 4:25 PM, Greg wrote: After much trial and error I fixed the problem. I know that I'm probably not going to win any fans here by complaining, but I feel that Apple could do a whole lot more to document the kernel. While searching for a potential solution I discovered an email on this mailing list, from myself, asking for information about the vnode_lookup function: The only reply I received was from Michael telling me to look through the kernel source for example uses, which I did, couldn't find any examples, replied as such, and received no further replies. My entire experience writing the kernel extension has been one of poking around in the dark. Since kernel programming is already such a difficult and dangerous task, why should it be made even *more* difficult by providing virtually zero documentation for the API? Should third-party developers really be expected to simply know everything there is to know about how Darwin works before attempting to write a KEXT? If that's the case at the very least that should be stated somewhere in one of the introductory texts Apple offers like "KEXTConcept" or "KernelProgramming". My problem was solved by a single vnode_put function call after the vnode_lookup. The only reason I was able to figure this out was because I somehow managed to find in the depths of the mailing list an unanswered email about what the difference between 'vnode_put' and 'vnode_rele' was, and so I figured perhaps I needed to "release" the vnode_t given to me by vnode_lookup, which was not at all obvious even after looking at the source for vnode_lookup. Sorry for the rant. Hopefully this email might prove useful for somebody else encountering the same problem. Release your vnodes! Hi, I'm encountering an odd problem, that seems to be occurring on both 10.4 and 10.5. I have a C-based kernel extension (_start/ _stop routines) that is loaded by a launchd daemon on startup and unloaded on shutdown (when the daemon gets a signal). The kernel reports (via printf messages) that it has been unloaded, in other words the _stop function was called, and it got to a point where all resources should have been freed and then it returns KERN_SUCCESS. However, the output on the screen stops at the following and sits there: Proper shutdown (when the KEXT is not installed) results in this output: I'd be very grateful for any ideas or theories as to why this is happening, what could be going wrong, as I'm not sure where to look, everything seems to be right.. This email sent to greg(a)kinostudios.com This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0