November 2001 - Darwin-kernel

Re: Is getpid supposed to return PID-1?
by justin＠mac.com 14 Nov '01

14 Nov '01

On Tuesday, November 13, 2001, at 06:29 , Kevin Bohan wrote: Hi, I have a BSD question and I apologise if this is not the right list, as this is not really my area. However I have a daemon that writes its PID to an external file when it starts up and I have a script that looks for this file, extracts the PID in order to provide a commandline interface that allows the process to be killed. However, when I call getpid to write the PID to the text file it always seems to write a value that is 1 less than the PID shown when I use ps to view the process in question. Also if I call kill on the value returned by getpid it tells me that the process doesn't exist. It would seem that ps is right an getpid is wrong. I can obviously just add one to the value returned by getpid, but is this safe/future-proof? Is this a known issue? What should I do? 'getpid()' is not likely to be wrong, so the smart money would bet that there's a "bug" in your code somewhere. At a guess, what is happening is that you call getpid() early in the process's existance, and that sometime after that, your code does a 'fork', with the parent (which is the process that called 'getpid()') exiting. Then the child continues on as the daemon (it's pid is different than the result of the earlier 'getpid()'). This is fairly standard for daemons, and is, in fact, what the daemon(3) call does. Regards, Justin PS: this is definitely the correct list. --- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | When LuteFisk is outlawed | Only outlaws will have | LuteFisk *--------------------------------------*-------------------------------*

1 0

Re: Is getpid supposed to return PID-1?
by Umesh Vaishampayan 13 Nov '01

13 Nov '01

On Tuesday, November 13, 2001, at 06:29 AM, Kevin Bohan wrote: Hi, I have a BSD question and I apologise if this is not the right list, as this is not really my area. However I have a daemon that writes its PID to an external file when it starts up and I have a script that looks for this file, extracts the PID in order to provide a commandline interface that allows the process to be killed. However, when I call getpid to write the PID to the text file it always seems to write a value that is 1 less than the PID shown when I use ps to view the process in question. Also if I call kill on the value returned by getpid it tells me that the process doesn't exist. It would seem that ps is right an getpid is wrong. I can obviously just add one to the value returned by getpid, but is this safe/future-proof? Is this a known issue? What should I do? Kirby You have a bug in your daemon. Care to post code for us to look at and find it? --Umesh -- Umesh Vaishampayan Apple Computer, Inc. Mac OS X Kernel Ph: (408) 974 0229

1 0

Mapping AFP Volume with Console Login
by Chris Edgington 13 Nov '01

13 Nov '01

I'm developing some OSX drivers. For other projects, I've always accessed my build machine over the network. I'm debugging my darwin driver with console output - so I'm just logging in through the full screen console. Is there a way to map a shared AFP volume from the console? In regular OSX Aqua mode - I just connect to the server from an alias, then the volume can be found in /Volumes/ShareVolName. Thanks, -Chris

1 0

Is getpid supposed to return PID-1?
by Kevin Bohan 13 Nov '01

13 Nov '01

Hi, I have a BSD question and I apologise if this is not the right list, as this is not really my area. However I have a daemon that writes its PID to an external file when it starts up and I have a script that looks for this file, extracts the PID in order to provide a commandline interface that allows the process to be killed. However, when I call getpid to write the PID to the text file it always seems to write a value that is 1 less than the PID shown when I use ps to view the process in question. Also if I call kill on the value returned by getpid it tells me that the process doesn't exist. It would seem that ps is right an getpid is wrong. I can obviously just add one to the value returned by getpid, but is this safe/future-proof? Is this a known issue? What should I do? Kirby _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

1 0

Re: wchar_t support at kernel level ?
by Francis Bouchard 13 Nov '01

13 Nov '01

Brian Bergstrand wrote something like : > > Not only that, but if you will be using wchar_t's for what most > people using them for (Unicode strings), there are two other > pitfalls. First, GCC is the only mainstream compiler that defines > wchar_t's as 32bit int's instead of 16bit ints. This will bite you in > the ass if you have code that does the following: > > wchar_t ustr[] = L"Hello World"; > > There are other cases where this causes trouble, but the above is the > most common. > This is exactly what I wanted to do... Hummm... Theses strings are used to identify the driver and things like that, but we must use unicode c'ause of Japanese... (so 16 bit...) Now, I have the opportunity to redefine a _MACRO_ WCHAR (widechar - 16 bit). I tried unsigned short, but then it does not allow me to initialize the string properly typedef unsigned short WCHAR; const WCHAR test[24] = L"bonjour"; This gives me an invalid initializer error. The goal is not to change the source code. This will allow me to get the source (from another departement) without having to change it every time and benefit from the bug fixes and more... I can play with the compilation environnements and the headers though. Any suggestions ? FRanics

1 0

Re: wchar_t support at kernel level ?
by Brian Bergstrand 12 Nov '01

12 Nov '01

At 2:02 PM -0800 11/12/01, Godfrey van der Linden wrote: I know our runtime support pretty well and we have done nothing in the kernel to support C++ wchar_t. As long as you don't require runtime support then you will be fine. All I can suggest is try compiling a sample kext and attempt to link it and see what happens. None of our infrastructure will understand whar_ts. Not only that, but if you will be using wchar_t's for what most people using them for (Unicode strings), there are two other pitfalls. First, GCC is the only mainstream compiler that defines wchar_t's as 32bit int's instead of 16bit ints. This will bite you in the ass if you have code that does the following: wchar_t ustr[] = L"Hello World"; There are other cases where this causes trouble, but the above is the most common. Secondly, if I remember correctly, the kernel deals with all path names in UTF-8, so if you are using wchar_t to interact with the filesystem layer at all, you may have to do some translation. Godfrey At 14:30 -0500 01-11-12, Francis Bouchard wrote: I guess my subject makes it clear! Is there any support at kernel level for the wchar_t type. My problem is I'm _porting_ (if I can use this term) a driver that makes use of it. So I looked at the EC++ spec and it says that it is a reserved keyword but not part of EC++. -- Brian Bergstrand <http://www.classicalguitar.net/brian/> PGP Key ID: 0xB6C7B6A2 No! Try not. Do, or do not. There is no try. - Yoda

1 0

Re: wchar_t support at kernel level ?
by Godfrey van der Linden 12 Nov '01

12 Nov '01

I know our runtime support pretty well and we have done nothing in the kernel to support C++ wchar_t. As long as you don't require runtime support then you will be fine. All I can suggest is try compiling a sample kext and attempt to link it and see what happens. None of our infrastructure will understand whar_ts. Godfrey At 14:30 -0500 01-11-12, Francis Bouchard wrote: I guess my subject makes it clear! Is there any support at kernel level for the wchar_t type. My problem is I'm _porting_ (if I can use this term) a driver that makes use of it. So I looked at the EC++ spec and it says that it is a reserved keyword but not part of EC++.

1 0

RE: IOLog at interrupt?
by Godfrey van der Linden 12 Nov '01

12 Nov '01

Not really, the sub-text I mentioned is just one of those kernel things that you 'just know' ;-). The problem is that people aren't born knowing it. Mostly in IOKit you don't have to worry about interrupt time as aside from Filters you never run at interrupt time, which is how this hole in the documentation came about. Godfrey At 16:44 -0500 01-11-12, Chris Edgington wrote: > The Filter is called on the primary hardware interrupt context. Very little of the system is available at this time. The IOLog doc says that you can't run at interrupt time, the sub text is that you can't call it at hardware interrupt time, or in IOKit terms at Filter time. Does this help? Sure ... but I don't see the sub text that you mention in the docs I'm looking at, maybe there's a better source for documentation ... I'm referring to: <http://developer.apple.com/techpubs/macosx/Darwin/Reference/Kernel/I OLib/Functions/Functions.html>http://developer.apple.com/techpubs/maco sx/Darwin/Reference/Kernel/IOLib/Functions/Functions.html <Hopefully the link won't wrap - converted message to HTML to keep that from happening.>

1 0

RE: IOLog at interrupt?
by Chris Edgington 12 Nov '01

12 Nov '01

> The Filter is called on the primary hardware interrupt context. Very > little of the system is available at this time. The IOLog doc says > that you can't run at interrupt time, the sub text is that you can't > call it at hardware interrupt time, or in IOKit terms at Filter time. > > Does this help? Sure ... but I don't see the sub text that you mention in the docs I'm looking at, maybe there's a better source for documentation ... I'm referring to: http://developer.apple.com/techpubs/macosx/Darwin/Reference/Kernel/IOLib/Fun ctions/Functions.html <Hopefully the link won't wrap - converted message to HTML to keep that from happening.> Thanks, -Chris

1 0

Re: IOLog at interrupt?
by Godfrey van der Linden 12 Nov '01

12 Nov '01

I think you are confusing the IOFilterInterruptEventSource FIlter and Action routines. Specifically the Action context is just the work loop. In general while you are on the work loop context you can do anything you want, except block for 'too' long. The Filter is called on the primary hardware interrupt context. Very little of the system is available at this time. The IOLog doc says that you can't run at interrupt time, the sub text is that you can't call it at hardware interrupt time, or in IOKit terms at Filter time. Does this help? Godfrey At 15:34 -0500 01-11-12, Chris Edgington wrote: The docs for IOLog say "IOLog should not be called from interrupt context." However, it appears that Apple breaks this rule - in AppleUSBOHCI_Interrupts.cpp they definitely call IOLog from PollInterrupts - which is called from InterruptHandler. Am I missing something or is the doc for IOLog not right? I'm porting some OS9 code to OSX. We've used DCON for debug output in the past, I'm trying to determine of IOLog will meet our needs as a replacement for DCON on OSX.

1 0