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

Re: The .nke check in Jaguar is NOT a good idea
by Stéphane Sudre 25 Jul '02

25 Jul '02

On Thursday, July 25, 2002, at 03:56 PM, Andrew Pinski wrote: Actually having the ability to load in kext/kne after the startup script is a good thing because when you install the kext/kne you can actually not make the user reboot the machine. In fact in Darwin 5.0(1.4) and even in 1.0 you can load in kext/kne after the startup script and even unload them and install a new version without rebooting. In fact when Mac OS X 10.1.2 came out, the SharedIP kext was busted, it would kernel panic when you connect to a local ip address (same machine). The problem was fixed in the Darwin's cvs, so downloaded the source and made the kext, unload the old one and loaded the new one up. It worked after that. I'm not saying it's useless to be able to load/unload a kext/nke at will. This is super useful when you're coding your kext/nke. I'm saying it's wrong that the System considers it can load a nke after its startup scripts. Because the nke can be working fine, the application too but the communication tunnel between them is not established and so the application may not work as it should. _______________________________________________ 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.

1 0

Re: How do disk writes work these days?
by Lally Singh 25 Jul '02

25 Jul '02

On 7/24/02 9:15 PM, "Wade Tregaskis" <wjtregaskis(a)students.latrobe.edu.au> wrote: >>> I don't recall any unix system in the past 30 years that did that. Disk >>> writes are scheduled by the I/O subsystem, and the driver handles >>> talking with the device to get the data there. All of this is >>> generally asynchronous with respect to process activity. >> >> I think Wade meant "block [the calling process on] any disk writes and >> yield time to other processes". Which is in fact what happens, both now >> and 30 years ago. > > Yes, that's what I meant. Sorry for the lack of clarity. :) > >> Wade -- one thing you might want to look in to is that some operating >> systems implement an asynchronous I/O API in addition to traditional >> blocking synchronous I/O. For asynch, the difference in the sequence of >> events (from userland POV) is that the initial I/O call doesn't block, >> and there is always some mechanism to notify the process of I/O >> completion. In "classic" MacOS, ISTR this was done by giving the OS a >> pointer to a callback function, which would be called on error or >> completion. I think it also set a flag in the descriptor structure used >> to request the I/O, so you could also determine completion by polling >> that flag. > > Is this still an efficient way of operating, in an increasingly linear [e. > g. single-user] OS? I'm just thinking, if you could return from writes > faster, the calling process can keep doing other things. My thought is > that you could do this without breaking existing apps by performing any > error checking [i.e. quickly verifying there is free space, among other > things] immediately, returning fail if appropriate, or otherwise returning > no error. You could then worry about physically getting the data to disk, > seeing as this is the most time intensive part... Think about it for a second. Timothy gave you some good reasons, too, but there's one very, very simple one too: when you give data to the disk drive to write, it's gotta go to the platter to save the data. This takes time, and since the write isn't done yet, the process that requested the write can't continue on. So, you may as well run another program :-) Timothy's response is more sophisticated, but it helps to spell out the obvious ;-) > > But, this from a newbie. I intend on acquiring some classic texts on this > subject [general OS level operations] - can anyone name one or two that > stand out? Design of the Unix Operating System, by Marice Bach. It's a little dated, but it's still correct where it matters. > _______________________________________________ > 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. _______________________________________________ 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.

1 0

Re: How do disk writes work these days?
by Timothy A. Seufert 25 Jul '02

25 Jul '02

Wade Tregaskis <wjtregaskis(a)students.latrobe.edu.au> wrote: Wade -- one thing you might want to look in to is that some operating systems implement an asynchronous I/O API in addition to traditional blocking synchronous I/O. For asynch, the difference in the sequence of events (from userland POV) is that the initial I/O call doesn't block, and there is always some mechanism to notify the process of I/O completion. In "classic" MacOS, ISTR this was done by giving the OS a pointer to a callback function, which would be called on error or completion. I think it also set a flag in the descriptor structure used to request the I/O, so you could also determine completion by polling that flag. Is this still an efficient way of operating, in an increasingly linear [e. g. single-user] OS? I'm just thinking, if you could return from writes faster, the calling process can keep doing other things. The classic way of doing this in UNIX systems is to make the application multithreaded. By splitting things into an I/O thread and a (other stuff) thread, you can avoid making the whole program stop every time it needs to do I/O. Of course, this often results in the program internally implementing mechanisms quite similar to async I/O completion notification. I'm not the one to ask whether doing I/O threads manually in user space or automatically in kernel space (which is basically what you end up with when you do async I/O APIs) is better. :) My thought is that you could do this without breaking existing apps by performing any error checking [i.e. quickly verifying there is free space, among other things] immediately, returning fail if appropriate, or otherwise returning no error. You could then worry about physically getting the data to disk, seeing as this is the most time intensive part... With the existing semantics for write(), it's not safe to do that precisely the way you describe. Programs can assume that it is safe to do anything with the buffers passed to write() after write() has returned. If there is a kernel thread still reading from them after write() returns, you could run into serious problems when the userland program overwrites or deallocates buffers before they have really been consumed. (Async I/O APIs require the user to keep the buffers valid until notification of I/O completion, of course.) Now, that's not to say that you can't get effectively what you have described. The key is that there must be enough free memory to cache the data written by the application. Most modern UNIXen (MacOS X included) can dynamically expand and shrink the amount of disk buffers to make the most use out of "free" memory that really isn't being used by anything. So, if you write 5 megabytes of data, and there's 10 megabytes of memory free, the system is probably going to just grab 5 MB of RAM for buffers, write the data to it, and return immediately. The semantics of write() are preserved, performance is better, everybody's happy. Of course, if there aren't enough free buffers for the I/O to complete immediately, and there isn't enough free memory to make new buffers, the system will block the calling process. Furthermore, some systems may (as a matter of policy) not allow write() to return until the data has really been written out to a disk -- or at least may not allow truly huge amounts of write buffering. I know that Linux is a system that is very aggressive about allowing you to fill free RAM with dirty disk buffers. Until you get down to about 5MB free or so, it will not be blocking much (if at all) on disk writes. I'm not quite sure what the rules are with OS X, though I am fairly sure it is nowhere near as aggressive as Linux. On Linux, you can do commands like: dd if=/dev/zero of=testfile bs=1048576 count=200 which writes 200 megabytes of zeroes to "testfile", and if you have enough memory free, it will finish VERY fast, before any data has really been written to disk. Then, a few seconds later, the disk light will come on solid as the kernel begins flushing the huge amount of dirty disk buffers it has accumulated. If you do this on OS X, the disk light will come on solid right away, and the command will not complete until the I/O has really finished. (Hard to tell if it's requiring every last byte to be written before returning; with modern disk transfer rates it could be allowing several megabytes of unwritten data and I wouldn't be able to tell by eye whether the disk light was staying on after dd finished.) There are positives and negatives to the extremely aggressive strategy of Linux, BTW. The positive is that if you don't run out of memory, everything is really really fast. The negative is that if you do, it can actually hurt performance. Plus, if the system should crash or lose power or whatever, there can be a whole lot of data in memory that has not been written out to disk, which can cause serious corruption on non-journaled filesystems. But, this from a newbie. I intend on acquiring some classic texts on this subject [general OS level operations] - can anyone name one or two that stand out? Tanenbaum & Woodhull's textbook "Operating Systems: Design and Implementation" is a classic introduction to the basic principles of operating system internals. It would definitely qualify as a "classic text", though: at least in the version I cut my teeth on, it covered the design of a UNIX-alike (Minix) which could run on 8088 based XT clones with floppy drives. Hopefully there's a newer edition which talks about somewhat more modern hardware. -- Tim Seufert _______________________________________________ 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.

1 0

Re: How do disk writes work these days?
by Wade Tregaskis 25 Jul '02

25 Jul '02

I don't recall any unix system in the past 30 years that did that. Disk writes are scheduled by the I/O subsystem, and the driver handles talking with the device to get the data there. All of this is generally asynchronous with respect to process activity. I think Wade meant "block [the calling process on] any disk writes and yield time to other processes". Which is in fact what happens, both now and 30 years ago. Yes, that's what I meant. Sorry for the lack of clarity. :) Wade -- one thing you might want to look in to is that some operating systems implement an asynchronous I/O API in addition to traditional blocking synchronous I/O. For asynch, the difference in the sequence of events (from userland POV) is that the initial I/O call doesn't block, and there is always some mechanism to notify the process of I/O completion. In "classic" MacOS, ISTR this was done by giving the OS a pointer to a callback function, which would be called on error or completion. I think it also set a flag in the descriptor structure used to request the I/O, so you could also determine completion by polling that flag. Is this still an efficient way of operating, in an increasingly linear [e. g. single-user] OS? I'm just thinking, if you could return from writes faster, the calling process can keep doing other things. My thought is that you could do this without breaking existing apps by performing any error checking [i.e. quickly verifying there is free space, among other things] immediately, returning fail if appropriate, or otherwise returning no error. You could then worry about physically getting the data to disk, seeing as this is the most time intensive part... But, this from a newbie. I intend on acquiring some classic texts on this subject [general OS level operations] - can anyone name one or two that stand out? _______________________________________________ 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.

1 0

Re: How do disk writes work these days?
by Timothy A. Seufert 24 Jul '02

24 Jul '02

"Justin C. Walker" <justin(a)mac.com> wrote: On Tuesday, July 23, 2002, at 07:18 AM, Wade Tregaskis wrote: [for background, I don't have any experience coding at the kernel level; I lurk on this list hoping to learn :)] This is probably a numbingly boring question, but what happens when the kernel gets handed data to write to disk, from say a userland app? I ask because I've begun covering this from a users point of view in my uni course, and they seem to indicate that the method, now as it was 30 years ago, is to block any disk write's and yield time to other processes. I don't recall any unix system in the past 30 years that did that. Disk writes are scheduled by the I/O subsystem, and the driver handles talking with the device to get the data there. All of this is generally asynchronous with respect to process activity. I think Wade meant "block [the calling process on] any disk writes and yield time to other processes". Which is in fact what happens, both now and 30 years ago. Wade -- one thing you might want to look in to is that some operating systems implement an asynchronous I/O API in addition to traditional blocking synchronous I/O. For asynch, the difference in the sequence of events (from userland POV) is that the initial I/O call doesn't block, and there is always some mechanism to notify the process of I/O completion. In "classic" MacOS, ISTR this was done by giving the OS a pointer to a callback function, which would be called on error or completion. I think it also set a flag in the descriptor structure used to request the I/O, so you could also determine completion by polling that flag. -- Tim Seufert _______________________________________________ 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.

1 0

Re: How do disk writes work these days?
by Justin C. Walker 23 Jul '02

23 Jul '02

On Tuesday, July 23, 2002, at 07:18 AM, Wade Tregaskis wrote: [for background, I don't have any experience coding at the kernel level; I lurk on this list hoping to learn :)] This is probably a numbingly boring question, but what happens when the kernel gets handed data to write to disk, from say a userland app? I ask because I've begun covering this from a users point of view in my uni course, and they seem to indicate that the method, now as it was 30 years ago, is to block any disk write's and yield time to other processes. I don't recall any unix system in the past 30 years that did that. Disk writes are scheduled by the I/O subsystem, and the driver handles talking with the device to get the data there. All of this is generally asynchronous with respect to process activity. Depending on the details of use and implementation, there are disk block or page caches to go through, but I can't imagine a system that would block disk writes. In any system that supports disk controllers that can be DMA masters, there's no need to do that. In the case of controllers that required "programmed I/O", the disk writes would still be fairly high priority, but would tend to block process activity. I'm curious if this is still how it's done. If not, what's the [basic] procedure? Get any book on operating systems; there is bound to be a reasonable, and fairly generic, discussion of this part of OS behavior. Regards, Justin -- /~\ The ASCII Justin C. Walker, Curmudgeon-at-Large \ / Ribbon Campaign X Help cure HTML Email / \ _______________________________________________ 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.

1 0

How do disk writes work these days?
by Wade Tregaskis 23 Jul '02

23 Jul '02

[for background, I don't have any experience coding at the kernel level; I lurk on this list hoping to learn :)] This is probably a numbingly boring question, but what happens when the kernel gets handed data to write to disk, from say a userland app? I ask because I've begun covering this from a users point of view in my uni course, and they seem to indicate that the method, now as it was 30 years ago, is to block any disk write's and yield time to other processes. I'm curious if this is still how it's done. If not, what's the [basic] procedure? _______________________________________________ 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.

1 0

RE: thread funnel and sbplio -solution
by Kevin Van Vechten 22 Jul '02

22 Jul '02

Quinn <eskimo1(a)apple.com> wrote: > At 21:05 +0200 22/7/02, George Andre wrote: > >This seems to me like material for a bug report, where does > >someone send these kinds of reports? > > <http://developer.apple.com/bugreporter/> > For Darwin components such as this, you can file a bug at: http://www.opendarwin.org/bugzilla/ (This particular issue is bug #37) Since you say it's no longer an issue in more current cvs versions, then there's a good chance the Apple's next release will address this issue. -Kevin _______________________________________________ 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.

1 0

RE: thread funnel and sbplio -solution
by Quinn 22 Jul '02

22 Jul '02

At 21:05 +0200 22/7/02, George Andre wrote: This seems to me like material for a bug report, where does someone send these kinds of reports? <http://developer.apple.com/bugreporter/> S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Technical Support * Networking, Communications, Hardware _______________________________________________ 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.

1 0

RE: thread funnel and sbplio -solution
by George Andre 22 Jul '02

22 Jul '02

Ok guys, I found the solution and the cause to my problem. I had left in code that used KUNCExecute() to spawn and execute an external program. So, in some mysterious way, most of the VOP_, vn_ and namei() worked even if the thread funnel was null, when this API was executed before. Now I got rid of the code using KUNCExecute and called thread_funnel_set() from start() and stop() and everything works correctly now, alltogether. This seems to me like material for a bug report, where does someone send these kinds of reports? Thanks for the assistance, George. > -----Original Message----- > From: darwin-kernel-admin(a)lists.apple.com > [mailto:darwin-kernel-admin@lists.apple.com]On Behalf Of George Andre > Sent: den 22 juli 2002 20:03 > To: Brian Bergstrand; georgea(a)bolina.hsb.se; > darwin-kernel(a)lists.apple.com > Subject: RE: thread funnel and sbplio > > > > >I'm getting a nasty panic while doing a VOP_GETATTR(). > > >It says that "splbio() not under funnel". Traced that > > >down to splbio() which checks for the current thread funnel. > > >I put some debug prints before the VOP_GETATTR() call and > > >the thread has no funnel held. So what I did was add a: > > > See below. > > > >thread_funnel_set(kernel_flock,TRUE) > > >respective > > >thread_funnel_set(kernel_flock,FALSE) around the VOP_GETATTR() > > >call, still with the same result... > > > > This should work. Are you sure you aren't making other calls > > requiring the kernel funnel after releasing it? > > > > Hi Brian, > > Yes, the panic is traced to the VOP_GETATTR call (commenting it out > doesn't crash the kernel). > > > Where in your code are you trying to call this. The kernel usually > > makes sure that you are under the correct funnel (which is probably > > why your other VOP calls work fine). Places where you don't > > automatically have the funnel and must acquire it yourself are: 1) > > Your kmod start/stop entry points, 2) Any new thread entry point, and > > 3) any timer callback. > > Well this is funny but I don't have the kernel funnel at all when > calling the other stuff and it works perfectly. All this stuff > is called from the start() method of a KEXT (actually 2 levels down). > I have 4 functions I've implemented (kfread, kfclose, kfopen and kfsize). > > kfopen,close and kfread work ok (with NO funnel, checked by debug printing > the value returned by thread_funnel_get()). These functions use > the NDINIT, > vn_open, VOP_UNLOCK, vn_rdwr, vn_close, without any failures and I'm able > to read from the file what I want.. What I can't do however is call > VOP_GETATTR safely in kfsize(). > > I've even put the whole kfsize() function inbetween thread_funnel_set's, > with exactly the same result. > > What I don't obviously do is have thread_funnel_set called first in my > start() and stop(). I'll try that immediately, but logically, it should > be the same as making sure the funnel is acquired for one > operation, right? > > I also read somewhere that funnels are released at rescheduling and > reacquired after. Can that have something to do with my situation? > > > PS. Please don't crosspost. Pick one list and send to that. If you > > don't get a response, try another list. > > 'Aight. :) > > Thanks, > George. > _______________________________________________ > 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. _______________________________________________ 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.

1 0