December 2001 - Darwin-kernel

Panic Feedback
by astarothia＠earthlink.net 27 Dec '01

27 Dec '01

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

1 0

Re: Proposed change to struct sockif
by Justin C. Walker 21 Dec '01

21 Dec '01

On Friday, December 21, 2001, at 08:32 , Josh Graessley wrote: We've run in to an issue with the sockif structure. The sf_sonewconn1 item in the structure is typed as follows: struct socket *(*sf_sonewconn1)(struct socket *, int, struct kextcb *); The real sonewconn function takes a socket* of a socket listening for connections, allocates a new socket*, fills it in and returns it. If an sf_sonewconn1 is specified it is called in sonewconn just after the socket structure as been allocate. The new socket* is passed as the first parameter. All of the other functions in that structure return an int. By returning an int, the other functions have the option of returning: 0 - no error, keep processing as usual EJUSTRETURN - everything is fine, don't process any further, just return Anything else - something went wrong, propagate the error Due to the definition, sf_sonewconn1 can not tell the caller it just wants the caller to return as if everything had succeeded (EJUSTRETURN). Is anyone using the sf_sonewconn1 item in the sockif structure? Does anyone see a need for a socket filter to return a different socket*? I'd like to change sf_sonewconn1 to: int (*sf_sonewconn1)(struct socket *, int, struct kextcb *); Or int (*sf_sonewconn1)(struct socket **, int, struct kextcb *); After off-line discussions, it seems like the right thing to do is to use the first suggested form, and check the int return value: - 0 => keep processing - EJUSTRETURN => return the just-allocted socket ('so') - other => return NULL (perhaps recording the error in so_error; I haven't thought that through yet The current situation is just bad code and bad thinking (I had an ill-formed idea that the intercept function might want to create its own socket, but it already has one which it can use). Also note that the current code will return a random value if an intercept function returns a non-null value (probably, that non-null value). Good catch. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Men are from Earth. | Women are from Earth. | Deal with it. *--------------------------------------*-------------------------------*

1 0

new doing a zero memory ?
by Francis Bouchard 21 Dec '01

21 Dec '01

Hi, please tell me if this is not the right list. I've been looking to know if the new in an IOKit of an object that does not inherit from OSObject. So I found in the sources (OSRuntime.cpp): 1 :void * operator new( size_t size) 2 :{ 3 : void * result; 4 : 5 : result = (void *) kern_os_malloc( size); 6 : if( result) 7 : bzero( result, size); 8 : return( result); 9 :} At line 7, it seems to do a zero memory. Is this not causing performance drop ? I found that because some of our old code rely on a new operator that is initializing the data. Is this initialization really necessary ? Franics

1 0

Proposed change to struct sockif
by Josh Graessley 21 Dec '01

21 Dec '01

We've run in to an issue with the sockif structure. The sf_sonewconn1 item in the structure is typed as follows: struct socket *(*sf_sonewconn1)(struct socket *, int, struct kextcb *); The real sonewconn function takes a socket* of a socket listening for connections, allocates a new socket*, fills it in and returns it. If an sf_sonewconn1 is specified it is called in sonewconn just after the socket structure as been allocate. The new socket* is passed as the first parameter. All of the other functions in that structure return an int. By returning an int, the other functions have the option of returning: 0 - no error, keep processing as usual EJUSTRETURN - everything is fine, don't process any further, just return Anything else - something went wrong, propagate the error Due to the definition, sf_sonewconn1 can not tell the caller it just wants the caller to return as if everything had succeeded (EJUSTRETURN). Is anyone using the sf_sonewconn1 item in the sockif structure? Does anyone see a need for a socket filter to return a different socket*? I'd like to change sf_sonewconn1 to: int (*sf_sonewconn1)(struct socket *, int, struct kextcb *); Or int (*sf_sonewconn1)(struct socket **, int, struct kextcb *); Thanks, -josh

1 0

basic questions...
by Andrew Gallatin 20 Dec '01

20 Dec '01

Hi, I'm an experienced unix (FreeBSD, Tru64) kernel programmer. I've been assigned to port a device driver for an OS bypass network cluster interconnect (PCI) card to Darwin/OS-X. I have a few basic questions that I'd like to ask here rather than learn the hard way. - Is having 2 Macs really the only way to debug kernels/drivers? It looks like they really have ripped out crashdumps, but is it possible to at least run ddb on the console? If so, how? Failing that, does anybody have a canned way to cross build gdb targeting Mach-o binaries on another type of unix host? Is it possible to attach to the kernel on the (same) running machine to explore data structures, etc? I work from home & the fewer boxes I have heating up the place, the better. - The "IOKitFundamentals" document hints that its possible for an IOKit driver to create a Posix device file. How? Will I get the standard open/close/ioctl/mmap (plus others) routines if I use the IOKit mechanisms? Or do I just call cdevsw_add()? Can somebody point me at an example IOKit driver which uses device nodes? - How stable is the UBC under memory pressure & how much memory is it safe for me wire down for communication? We're typically able to wire down between 1/2 and 3/4 of physical memory on other platforms... - Is one supposed to edit $MYDRIVER/$MYDRIVER.pbproj to add matching information? I'd just do it, but it looks like a machine generated file & the mac "finder" gui doesn't even let you open the directory, so I'm assuming there's a "right way" to edit this file & am wondering what it is. I haven't found any menu that looks right in the Project Builder IDE. But then again, I'm used to using vi & make as my build environment, so its quite possible I haven't looked in the right place. Thanks for the help, Drew Gallatin

1 0

Re: kernel mode
by justin＠mac.com 17 Dec '01

17 Dec '01

On Saturday, December 15, 2001, at 09:56 , Jawahar M wrote: i believe apple display drivers, office and browser should run in kernel mode... This is what is known in some circles as a non sequitur. Jawahar, do you have a question? Are you replying to some previous question or mail? Perhaps if you gave more context, it would help. Regards, Justin -- /~\ The ASCII Justin C. Walker, Curmudgeon-at-large \ / Ribbon Campaign X Against HTML / \ Email!

1 0

Re: kernel mode
by David W. Halliday 17 Dec '01

17 Dec '01

Jawahar M wrote: > i believe apple display drivers, office and browser should run in kernel > mode... > > jawahar Is this a troll, or what? I'm reasonably certain that all display drivers (as opposed to drawing code, such as QuickDraw and Quartz 2D/3D) is done in kernel mode. However, user applications, like office applications and browsers, should /never/ even be considered for running in kernel mode: 1) the kernel is resource limited, compared to user applications; and 2) such applications tend to be too unstable, so they could bring down the entire system if run in such a mode (it's bad enough that so many hardware drivers are run in this mode [Apple is working on minimizing this as well]). Is it just that this person longs for the bad old days of the classic Mac OS (and DOS, and other older systems) where everything was run at the same privilege level on the processor? Where everything could touch all aspects of the system at all times? When anything could bring the entire system crashing around the user's ears? When all applications could stomp on all other applications? No thanks! David Halliday(a)WebWizardry.net

1 0

kernel mode
by Jawahar M 16 Dec '01

16 Dec '01

i believe apple display drivers, office and browser should run in kernel mode... jawahar

1 0

Re: UFS not 64-bit clean?
by Chris Bednar 13 Dec '01

13 Dec '01

> > Hmmm, also.... please don't ask me why I did this: > > > >> @@ -366,7 +366,7 @@ > >> #endif /* REV_ENDIAN_FS */ > >> > >> brelse(bp); > >> - return (EIO); /* XXX needs translation */ > >> + /*return (EIO); XXX needs translation */ > > > > > > I wonder why it did not panic later when you brelse(bp) the same buffer > again.... > > 386 brelse(bp); Well, please note that, although I can't think of any reason I would have commented out the return there (well, OK; the reason had something to do with 2am, I guess), it has nothing to do with the panic. Aside from the fact that the conditions at line 361 are not met, I don't see any reason ffs_reload() would be getting called here... ---- Chris J. Bednar Director, Distributed Computing Product Group http://AdvancedDataSolutions.com/

1 0

Re: Support of dummynet in ipfw for bandwidth limiting
by justin＠mac.com 13 Dec '01

13 Dec '01

This won't be quick. Dummynet lives down in the bowels of the networking subsystem of the kernel, where we've done major, um, reconstructive surgery. If you want to give it a shot, you'll need to learn about DLIL and the NKE mechanisms in Darwin, for which there is, yet, no documentation to speak of. You can check the file NKE.pdf in the /Developer/Documentation tree for documentation that was done at the beginning of the work; it's good in overall concepts, but the details diverged a while back (and continue to do so). Regards, Justin On Thursday, December 13, 2001, at 02:14 , Chris Lewicki wrote: Hi, I'd like to bandwidth limit some services coming from my Mac OS X machine, and the use of ipfw w/dummynet (http://info.iet.unipi.it/~luigi/ip_dummynet/) seemed like the easiest and most appropriate thing for my application. However, it would seem that dummynet is not supported in Darwin, despite the presence of a few header files throughout the system to the contrary. When trying to add a pipe and configure it I get the following error: ipfw: setsockopt(IP_DUMMYNET_CONFIGURE): Protocol not available So, my question: Is anyone working on a port? I gave a quick try from FreeBSD sources, but haven't had much luck. I think I'm missing things like ip_dummynet.c, bridge.c etc.... Also, while I've been able to recompile a working IPFirewall kernel extension, perhaps I need to be updating /sbin/ipfw as well? But where's the source? Can't seem to find an Apple version of it anywhere. Anyway, hope this finds a quick solution. Thanks! -Chris _______________________________________________ darwin-kernel mailing list | darwin-kernel(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored. --- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Men are from Earth. | Women are from Earth. | Deal with it. *--------------------------------------*-------------------------------*

1 0