January 2002 - Darwin-kernel

Shared memory, rpc
by samuel＠ibrium.se 07 Jan '02

07 Jan '02

Hi! I'm working on porting Mac-on-Linux (MOL) from linux/ppc to Darwin. The linux source consists of two parts; a kernel module and a userspace program. I intend to use the same setup on Mac OS X (the kernel module creates and maintains a virtualized environment with full MMU support by hooking the exception vectors). I have a few questions: - Is it possible for the kernel extension and the user task to share a few pages of memory? Basically the virtualized CPU state needs to be directly accessible from both contexts (by performance reasons). The available documentation seems to imply that the above is impossible (?). As a last resort, couldn't one just lock down a user page, take the physical address of it and map it into the kernel address space? - Is there some sample code available showing how to properly export RPC routines from a kernel extension to userland? I have played around a bit with mig and things are starting to make sense, but some sample code would be useful. /Samuel

1 0

Re: Panic Feedback
by Andrew Gallatin 06 Jan '02

06 Jan '02

Umesh Vaishamapayan writes: > On Friday, January 4, 2002, at 06:08 PM, Umesh Vaishamapayan wrote: > > > > >> or at > >> least optionally expose a console interface to ddb so that one can get > >> a symbolic stack trace (like you can with the ddb in *BSD & Tru64)? > >> > > > > Well, if you build and run DEBUG kernel, you get ddb... > > > > A clarification: > > You get Mach kdb [which is similar to FreeBSD ddb] Excellent! That's exactly what I want. Thanks for the tip. Now, to figure out how to get my dual g4 800 to actually boot a different kernel than the default one.. :) Drew

1 0

Re: Panic Feedback
by Umesh Vaishamapayan 05 Jan '02

05 Jan '02

On Friday, January 4, 2002, at 06:08 PM, Umesh Vaishamapayan wrote: or at least optionally expose a console interface to ddb so that one can get a symbolic stack trace (like you can with the ddb in *BSD & Tru64)? Well, if you build and run DEBUG kernel, you get ddb... A clarification: You get Mach kdb [which is similar to FreeBSD ddb] --Umesh

1 0

Re: Panic Feedback
by Umesh Vaishamapayan 05 Jan '02

05 Jan '02

On Friday, January 4, 2002, at 06:21 AM, Andrew Gallatin wrote: Umesh Vaishamapayan writes: Thanks for the feedback. Fortunately you are not the only one who does not like the current panic UI [I wonder why? :-)] So there is already Radar tracking the issue of improving the panic UI. Speaking of the panic UI .. As a new Darwin driver developer coming from a FreeBSD (and Tru64) background, I've found it incredibly painful to analyze a panic with only one Darwin system. Are there any plans to implement either crashdumps for post-mortem debugging Crashdump like FreeBSD are not possible in Darwin because there is no swap partition to dup to. We swap to the file system, and in case of a panic/crash you do not want to write to your file system. You might want to check Darwin-developer list archives. This has been discussed at length in the past. or at least optionally expose a console interface to ddb so that one can get a symbolic stack trace (like you can with the ddb in *BSD & Tru64)? Well, if you build and run DEBUG kernel, you get ddb... --Umesh

1 0

Re: Panic Feedback
by Andrew Gallatin 04 Jan '02

04 Jan '02

Umesh Vaishamapayan writes: > Thanks for the feedback. Fortunately you are not the only one who does > not like the current panic UI [I wonder why? :-)] So there is already > Radar tracking the issue of improving the panic UI. > Speaking of the panic UI .. As a new Darwin driver developer coming from a FreeBSD (and Tru64) background, I've found it incredibly painful to analyze a panic with only one Darwin system. Are there any plans to implement either crashdumps for post-mortem debugging or at least optionally expose a console interface to ddb so that one can get a symbolic stack trace (like you can with the ddb in *BSD & Tru64)? Cheers, Drew

1 0

Re: Panic Feedback
by Umesh Vaishamapayan 04 Jan '02

04 Jan '02

Thanks for the feedback. Fortunately you are not the only one who does not like the current panic UI [I wonder why? :-)] So there is already Radar tracking the issue of improving the panic UI. On Thursday, December 27, 2001, at 02:50 AM, astarothia(a)earthlink.net wrote: Hi all, I joined this list mostly to observe and learn a little without getting in the way, but I thought I'd offer an idea I have been thinking about. Apple has done a great job of hiding the CLI from the average user, while leaving access for the advanced users in place. Further, I think it's great that Apple asks users to report information generated during a panic, but should they need to read a KBase article to realize that? If I'm a user who's never heard of a kernel panic and I suddenly get thrown out of my warm and fuzzy Aqua and into some strange text dump, I'm probably not going to consider writing down what appears on the screen. "We're hanging here..." is enough for a developer or advanced user to know what's going on and the correct procedure, but why not offer an explanation and directions for the general user? I'm not a kernel hacker, but it looks like you could just add a printf and something along the lines of the following: "Mac OS X has crashed and the system must be restarted. Please record the entire text that was generated on the screen to aid Apple in investigating the cause of this error. For information on how to report a kernel panic, please visit http://www.apple.com/support/." or something akin to that. Panics are extremely rare under OS X (for most people anyway), but I believe including a simple message to the user, such as the above, would greatly increase the likelihood that people would report them when they do occur. - George The goal is to make it even easier to report than what you propose.... --Umesh -- Umesh Vaishampayan Mac OS X kernel group Ph: (408) 974 0229

1 0