November 2001 - Darwin-kernel

IOLog at interrupt?
by Chris Edgington 12 Nov '01

12 Nov '01

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. Thanks, -Chris

1 0

wchar_t support at kernel level ?
by Francis Bouchard 12 Nov '01

12 Nov '01

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++. Thanks Francis

1 0

Re: devfs user client
by Kevin Van Vechten 10 Nov '01

10 Nov '01

Hello Godfrey, Thanks for the quick reply. As a note, in my first email I think I was using the term "callback" too loosely (as a concept not an implementation). Your reply made sense. I like the idea of notifying the user process with a token, and then letting the process call back into the userclient with the token to get at the data. vm_map_copy{in,out} looks like it will do the job. What mechanism should be used to notify the user process of activity on the devfs entry? Could I use an IONotificationPort for that? Thanks, Kevin On Friday, November 9, 2001, at 03:41 PM, Godfrey van der Linden wrote: G'day Kevin, First thing I note is that callbacks just "ain't" gonna work. We should recognise that the other end of the /dev/... device is going to be a server out in user land. This server has a thread that is dedicated to behaving like a driver. It is this thread that will recieve notifications when completion routines need to be run. The memory stuff does bare some thought. What would be ideal is if we don't even move the data out into user land in the first place. All we move out is a handle that can be passed back into the kernel and translated into user land memory again. I believe that vm_map_copy{in,out} may come to our rescue here. Resource limitation could be achieved by allocating 'struct buf' equivalents that are setup on a per devfs level. Say 8 or 16 I/Os in flight per device or per client & device? Did any of this make any sense? I'm afraid that I can probably give architectural advice (hey advice is cheap, especially mine). The problem is that for the next 5 weeks I'm snowed under with MacWorld deliverables then I'm going home to Australia for a month . Godfrey At 13:53 -0800 01-11-9, Kevin Van Vechten wrote: Hello Godfrey, I'm hoping to resurrect discussion about a devfs user client. The initial steps don't look too bad: make a IODevfs extension which can modify devfs and a IODevfsUserClient which issues requests to the extension. Things get trickier with the bdevsw and cdevsw callbacks. It would be nice to provide a fairly-high bandwidth mechanism for moving blocks between the kernel and user land. Also it seems like care should be taken to help prevent a user process from bogging down the kernel. When the callbacks are invoked should they send a mach message describing the event to the user process? The messages could be handled in code provided by the IODevfsUserClient, which would interpret the messages and then make calls into the user process similar to the bdevsw and cdevsw callbacks, maybe even identically, which would allow for easy porting. What are your current thoughts on how to implement the bdevsw and cdevsw callbacks? Thanks, Kevin

1 0

Re: devfs user client
by Godfrey van der Linden 09 Nov '01

09 Nov '01

G'day Kevin, First thing I note is that callbacks just "ain't" gonna work. We should recognise that the other end of the /dev/... device is going to be a server out in user land. This server has a thread that is dedicated to behaving like a driver. It is this thread that will recieve notifications when completion routines need to be run. The memory stuff does bare some thought. What would be ideal is if we don't even move the data out into user land in the first place. All we move out is a handle that can be passed back into the kernel and translated into user land memory again. I believe that vm_map_copy{in,out} may come to our rescue here. Resource limitation could be achieved by allocating 'struct buf' equivalents that are setup on a per devfs level. Say 8 or 16 I/Os in flight per device or per client & device? Did any of this make any sense? I'm afraid that I can probably give architectural advice (hey advice is cheap, especially mine). The problem is that for the next 5 weeks I'm snowed under with MacWorld deliverables then I'm going home to Australia for a month . Godfrey At 13:53 -0800 01-11-9, Kevin Van Vechten wrote: Hello Godfrey, I'm hoping to resurrect discussion about a devfs user client. The initial steps don't look too bad: make a IODevfs extension which can modify devfs and a IODevfsUserClient which issues requests to the extension. Things get trickier with the bdevsw and cdevsw callbacks. It would be nice to provide a fairly-high bandwidth mechanism for moving blocks between the kernel and user land. Also it seems like care should be taken to help prevent a user process from bogging down the kernel. When the callbacks are invoked should they send a mach message describing the event to the user process? The messages could be handled in code provided by the IODevfsUserClient, which would interpret the messages and then make calls into the user process similar to the bdevsw and cdevsw callbacks, maybe even identically, which would allow for easy porting. What are your current thoughts on how to implement the bdevsw and cdevsw callbacks? Thanks, Kevin

1 0

devfs user client
by Kevin Van Vechten 09 Nov '01

09 Nov '01

Hello Godfrey, I'm hoping to resurrect discussion about a devfs user client. The initial steps don't look too bad: make a IODevfs extension which can modify devfs and a IODevfsUserClient which issues requests to the extension. Things get trickier with the bdevsw and cdevsw callbacks. It would be nice to provide a fairly-high bandwidth mechanism for moving blocks between the kernel and user land. Also it seems like care should be taken to help prevent a user process from bogging down the kernel. When the callbacks are invoked should they send a mach message describing the event to the user process? The messages could be handled in code provided by the IODevfsUserClient, which would interpret the messages and then make calls into the user process similar to the bdevsw and cdevsw callbacks, maybe even identically, which would allow for easy porting. What are your current thoughts on how to implement the bdevsw and cdevsw callbacks? Thanks, Kevin

1 0