February 2005 - Darwin-dev - lists.apple.com

Re: Serial port arbitration (UUCP device locking protocol?)
by Dan Bernstein 14 Feb '05

14 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=k81CRYgZOTrmkpvSqBqNrg1Lkj9BV+uPNiOfwXcyOjWKkWn0ZqjB8q64q/GzDCKf8x4tY+K7llqwVc4qrPeYb4Vfcb9BRGFS0/SCULj2WoL1OUOev2mSSYeDkM5nPPL5XIGVlZg/qoVgcif6qC/O+J5McCgu0wV0fRrN4fHRICY= Thanks! It doesn't get any better than a detailed reply from an Apple engineer that includes sample code and doesn't include "please file a bug" :-) One question, though. When you say > // At this point you have the port exclusively and non-preemtibly > // so now is a good time to program up the modem or do any other > // equipment initialisation you desire. How do I do that? Can I just write to the dialin device or should I open the dialout? -- Dan On Sat, 12 Feb 2005 11:47:00 -0800, Godfrey van der Linden <gvdl(a)apple.com> wrote: > G'day Dan, > > I'll use this email to write up IOSerialFamily arbitration then I'll > add a man page, probably ioss(4). > > The traditional UNIX arbitration has some serious limitations. One of > which is that it is very difficult to have a port open waiting for a > fax or data connection and then allow the computer to dial out. > Traditionally this problem was solved with lock files that often > contain PIDs. However there are so many different types and > implementations of the lock file method it is rarely reliable, > especially in an opensource environment. > > So when I studied the various different implementations around when > asked to work on the NeXT serial ports I felt that the tty.*/cu.* > mechanism was the cleanest. In those days the modem cable could be > relied upon to correctly wire the carrier detect line. The semantic > was clean that is the getty could open the tty.* line and it would > block until carrier was raised. While the getty was blocked in open > the cu.* line could be opened arbitrarily. The worked very well. > > The problem came with fax modems which do not raise the carrier and > Mac's which don't usually wire carrier into their serial cables. When > this happens the enitire NeXT/BSD arbitration model breaks down. Yet I > still liked the basic model. A couple of years ago (yes it has taken a > long time to document this hasn't it, my only excuse is that I have > been busy ;-) I had a hard look at serial arbitration and did a bit of > comparative research and it seemed that the state of the art was to use > UUCP style lock files. I just hated that solution. So I chose to stick > with the basic design of the NeXT/BSD model but implement the concept > of preemptable ports. > > One other thing before I go into the details. Traditionally UNIX will > allow multiple clients to open the same serial port. It provided the > TIOCEXCL flag as a mechanism to fail future opens of the same port but > TIOCEXCL had the problem of not being atomic. Hence it was possible > for 2 processes to successfully open the port then both attempt to > promote it to exclusive access, they would both succeed. I changed the > implementation of TIOCEXCL to provide for a true atomic test. If one > process attempts to lock exclusively and another process has beaten it > then the ioctl will fail. > > Finally there had to be a mechanism to work out whether an exclusive > port became idle. I couldn't use a blocking open() statement as it was > supposed to return failure if the port was set to be exclusive. And I > didn't like the idea of creating another minor device to exclusively > for blocking a port and I obviously couldn't use an ioctl (you need an > open port to do that). Being an IOKit architect I decided to use the > IOKit model to control this behaviour. To the end I have created a new > "property" called waitForIdle that will block, interruptibly, till the > serial port goes idle, i.e. neither the cu.* nor the tty.* line is > currently open. > > So putting all of this together to reliably open a serial port on > MacOSX use the following procedure, note there are still race > conditions involved but you can be reasonably certain that you have a > port reliably. > > To open a dialin device (getty/efax), NB this is code I have written of > the top of my head and hasn't been compiled, I make no promises that it > works as written you may need to fix minor errors in spelling. > > #include <IOKit/serial/ioss.h> > #include <IOKit/serial/IOSerialKeys.h> > > // iterate over I/O registry to find desired node and keep your > // registry entry node (See DTS docs for a write up on how to do > this) > io_registry_entry_t portre = <do the search> > > int fd; > int preempt; > > tryAgain: > for (;;) { > do { > fd = open(<tty.dialindevice>, O_NONBLOCK); > if (-1 == fd) > if (EBUSY == errno) > continue; > else > exit(1); // Fatal error > > // clear O_NONBLOCK flag > if (-1 == fcntl(fd, F_SETFL, 0)) > exit(1); // fatal error > > if (-1 == ioctl(fd, TIOCEXCL, 0)) > if (EBUSY == errno) { > close(fd); > fd = -1; > continue; > } > else > exit(1); // Fatal error > } while(false); > > if (-1 != fd) > break; > > // We must have had an EBUSY error to be here so wait for idle > if (kIOReturnSuccess != IORegistryEntrySetProperty(portre, > CFSTR(kIOTTYWaitForIdleKey), kCFBooleanTrue) > exit(1); // Fatal error > > }; > > // At this point you have the port exclusively and non-preemtibly > // so now is a good time to program up the modem or do any other > // equipment initialisation you desire. > > preempt = 0;` > if (-1 == ioctl(fd, IOSSPREEMPT, &preempt)) > exit(1); // Fatal error > > // Now the port is in the preemptible - blocking state > // time to issue a blocking read or a select as needed > // waiting for whatever event you are want. > if (-1 == read(fd, buf, sizeof(buf)) // Pseudo code > if (EIO == errno) { > close(fd); // We have been preempted. > goto tryAgain; > } > else > exit(1); // probably fatal > > // We have a connection and it is time to say we are no longer > // preemptible > preempt = 1; > if (-1 == ioctl(fd, IOSSPREEMPT, &preempt)) > exit(1); // Fatal error > > // That's it while we are running non-preemtibly/exclusive further > // attempts to open the port on either cu.* or tty.* will fail with > EBUSY > > That is about it, I should note that the callout line is much simpler > but if it gets EBUSY returned from the open it should also spin around > kIOTTYWaitForIdleKey property. > > Hope this helps > > Godfrey van der Linden > IOSerialFamily (for my sins) > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Pointer on howto provide a /dev/node
by Godfrey van der Linden 14 Feb '05

14 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Godfrey On Feb 14, , at 3:05, Hado Hein wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Sorry Hado, there is no interface to create /dev/... nodes without being in the kernel. We have briefly thought about user land drivers but it does present some nasty problems and hasn't reached the top of our priority lists. *IOSerial~ show some steps how to mount something in /dev via IOKit but that seems to be kernel - I#d prefer a userland process. This email sent to site_archiver(a)lists.apple.com

1 0

Fwd: Pointer on howto provide a /dev/node
by appledisclose＠batchmaker.de 14 Feb '05

14 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: handmade ! User-agent: MacSOUP/D-2.5 (Mac OS X version 10.3.8) I had this on darwin-userlevel which is not right says lists.apple.com. It should go here. For some of my usb toys I'd like to provide the data on /dev nodes cause there is a similar interface structure for programs on linux. So I have working usb drivers using IOKit (in an userland app). Now I'd like provide that data in /dev with a userland daemon instead. Where can read something about this ? I'd prefer some short words on - what functions to call for registering the node in devfs ( usr/.../miscfs/devfs/) give me not really a clue on the steps.* - where and what function under which name (r,w,ioctl) to implement so that the node and its code get called if someone opens the filenode and freads. *IOSerial~ show some steps how to mount something in /dev via IOKit but that seems to be kernel - I#d prefer a userland process. thx, Hado -- Hado Hein, Berlin, Fed.Rep. of Germany http://www.batchmaker.de (software authoring, including stage lighting) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

shm tries
by appledisclose＠batchmaker.de 14 Feb '05

14 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: handmade ! User-agent: MacSOUP/D-2.5 (Mac OS X version 10.3.8) I'm doing trial on a software that will allocate a lot of shm segments. At the moment I'm doing just one shmget, but tend to do hundreds of them When I terminate the app in the debugger them shms are staying in ram. Is there a way, besides a restart as i'm doing now, that can clear those straw segments cause I haven't called shmdt on them while debugging. -- Hado Hein, Berlin, Fed.Rep. of Germany http://www.batchmaker.de (software authoring, including stage lighting) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Problems with compiling xnu-517.11.1
by Kevin Van Vechten 14 Feb '05

14 Feb '05

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com - Kevin On Feb 13, 2005, at 2:33 PM, Benjamin Herrenschmidt wrote: It seems the file osfmk/ppc/machine_routines_asm.s is incomplete, it's bit "cropped" in half some way ... _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Ben's diagnosis is correct. I'll try to post a fix with the complete version of this file tomorrow. Ben. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Problems with compiling xnu-517.11.1
by Benjamin Herrenschmidt 13 Feb '05

13 Feb '05

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com On Sat, 2005-02-12 at 12:05 +0100, Michael Tuexen wrote: > From: Michael.Tuexen(a)lurchi.franken.de > Subject: Problems with compiling xnu-517.11.1 > Date: February 12, 2005 11:59:55 Uhr CET > To: darwin-development(a)lists.apple.com > > Dear all, > > I've downloaded the xnu-517.11.1 sources and a > > .../... It seems the file osfmk/ppc/machine_routines_asm.s is incomplete, it's bit "cropped" in half some way ... Ben. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Serial port arbitration (UUCP device locking protocol?)
by Godfrey van der Linden 12 Feb '05

12 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com G'day Dan, #include <IOKit/serial/ioss.h> #include <IOKit/serial/IOSerialKeys.h> int fd; int preempt; tryAgain: for (;;) { do { fd = open(<tty.dialindevice>, O_NONBLOCK); if (-1 == fd) if (EBUSY == errno) continue; else exit(1); // Fatal error // clear O_NONBLOCK flag if (-1 == fcntl(fd, F_SETFL, 0)) exit(1); // fatal error if (-1 == ioctl(fd, TIOCEXCL, 0)) if (EBUSY == errno) { close(fd); fd = -1; continue; } else exit(1); // Fatal error } while(false); if (-1 != fd) break; // We must have had an EBUSY error to be here so wait for idle if (kIOReturnSuccess != IORegistryEntrySetProperty(portre, CFSTR(kIOTTYWaitForIdleKey), kCFBooleanTrue) exit(1); // Fatal error }; // At this point you have the port exclusively and non-preemtibly // so now is a good time to program up the modem or do any other // equipment initialisation you desire. preempt = 0;` if (-1 == ioctl(fd, IOSSPREEMPT, &preempt)) exit(1); // Fatal error // Now the port is in the preemptible - blocking state // time to issue a blocking read or a select as needed // waiting for whatever event you are want. if (-1 == read(fd, buf, sizeof(buf)) // Pseudo code if (EIO == errno) { close(fd); // We have been preempted. goto tryAgain; } else exit(1); // probably fatal // We have a connection and it is time to say we are no longer // preemptible preempt = 1; if (-1 == ioctl(fd, IOSSPREEMPT, &preempt)) exit(1); // Fatal error Hope this helps Godfrey van der Linden IOSerialFamily (for my sins) _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I'll use this email to write up IOSerialFamily arbitration then I'll add a man page, probably ioss(4). The traditional UNIX arbitration has some serious limitations. One of which is that it is very difficult to have a port open waiting for a fax or data connection and then allow the computer to dial out. Traditionally this problem was solved with lock files that often contain PIDs. However there are so many different types and implementations of the lock file method it is rarely reliable, especially in an opensource environment. So when I studied the various different implementations around when asked to work on the NeXT serial ports I felt that the tty.*/cu.* mechanism was the cleanest. In those days the modem cable could be relied upon to correctly wire the carrier detect line. The semantic was clean that is the getty could open the tty.* line and it would block until carrier was raised. While the getty was blocked in open the cu.* line could be opened arbitrarily. The worked very well. The problem came with fax modems which do not raise the carrier and Mac's which don't usually wire carrier into their serial cables. When this happens the enitire NeXT/BSD arbitration model breaks down. Yet I still liked the basic model. A couple of years ago (yes it has taken a long time to document this hasn't it, my only excuse is that I have been busy ;-) I had a hard look at serial arbitration and did a bit of comparative research and it seemed that the state of the art was to use UUCP style lock files. I just hated that solution. So I chose to stick with the basic design of the NeXT/BSD model but implement the concept of preemptable ports. One other thing before I go into the details. Traditionally UNIX will allow multiple clients to open the same serial port. It provided the TIOCEXCL flag as a mechanism to fail future opens of the same port but TIOCEXCL had the problem of not being atomic. Hence it was possible for 2 processes to successfully open the port then both attempt to promote it to exclusive access, they would both succeed. I changed the implementation of TIOCEXCL to provide for a true atomic test. If one process attempts to lock exclusively and another process has beaten it then the ioctl will fail. Finally there had to be a mechanism to work out whether an exclusive port became idle. I couldn't use a blocking open() statement as it was supposed to return failure if the port was set to be exclusive. And I didn't like the idea of creating another minor device to exclusively for blocking a port and I obviously couldn't use an ioctl (you need an open port to do that). Being an IOKit architect I decided to use the IOKit model to control this behaviour. To the end I have created a new "property" called waitForIdle that will block, interruptibly, till the serial port goes idle, i.e. neither the cu.* nor the tty.* line is currently open. So putting all of this together to reliably open a serial port on MacOSX use the following procedure, note there are still race conditions involved but you can be reasonably certain that you have a port reliably. To open a dialin device (getty/efax), NB this is code I have written of the top of my head and hasn't been compiled, I make no promises that it works as written you may need to fix minor errors in spelling. // iterate over I/O registry to find desired node and keep your // registry entry node (See DTS docs for a write up on how to do this) io_registry_entry_t portre = <do the search> // That's it while we are running non-preemtibly/exclusive further // attempts to open the port on either cu.* or tty.* will fail with EBUSY That is about it, I should note that the callout line is much simpler but if it gets EBUSY returned from the open it should also spin around kIOTTYWaitForIdleKey property. This email sent to site_archiver(a)lists.apple.com

1 0

Problems with compiling xnu-517.11.1
by Michael Tuexen 12 Feb '05

12 Feb '05

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com From: Michael.Tuexen(a)lurchi.franken.de Subject: Problems with compiling xnu-517.11.1 Date: February 12, 2005 11:59:55 Uhr CET To: darwin-development(a)lists.apple.com Dear all, Does anyone know how to proceed? Best regards Michael _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… I've downloaded the xnu-517.11.1 sources and a source SETUP/setup.csh make exporthdrs make all results in /usr/bin/strip -S -x /Users/tuexen/Documents/xnu-517.11.1/BUILD/obj/RELEASE_PPC/./ mach_kernel.sys -o /Users/tuexen/Documents/xnu-517.11.1/BUILD/obj/RELEASE_PPC/./ mach_kernel; /usr/bin/ld: Undefined symbols: _cacheDisable _cacheInit _clock_get_uptime _cpu_number _mach_absolute_time _machine_idle_ret _ml_get_timebase _ml_read_temp _ml_scom_read _ml_scom_write _ml_set_processor_speed_dfs _ml_set_processor_speed_dpll _ml_set_processor_speed_powertune _ml_thrm_init _set_machine_current_act _current_act _current_thread make[2]: *** [do_build_mach_kernel] Error 1 make[1]: *** [build_all] Error 2 make: *** [all] Error 2 This email sent to site_archiver(a)lists.apple.com

1 0

Re: Serial port arbitration (UUCP device locking protocol?)
by Dan Bernstein 12 Feb '05

12 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=k34cH7Ncq+jtM8fzPmxM2PpssSWWL9cUPMb/UmnRQjv1QrC9G3t1zWzRG3uVTUZnzZyqo52ZWbSnuG4LZT9WNisrmnxFa0yCb+jY9oaIEjzuByjUanmq4KxPnAR3LAVcHT/y1+TvuGeSeJ4peYQDqakj1o7MnT2PUry4Fy3x9CE= Thanks. That's something, but not quite what I'd hoped for. Is there a way that I could tell when another program has opened the "call-out device", and more importantly, when it has closed it, so that I can put the modem back into a known state? -- Dan On Fri, 11 Feb 2005 12:23:24 -0800, Mike Smith <msmith(a)freebsd.org> wrote: > > I couldn't find any documentation or discussion of serial port > > arbitration in darwin or Mac OS X. The situation is the classic one: I > > want my program to listen on the modem port but yield it to any other > > program wishing to use it. The efax man page mentions the "UUCP device > > locking protocol", but this appears to be useful only if all other > > applications adhere to it. Is Open Transport's arbitration mechanism > > supported under Mac OS X? If so, what does it use on the darwin level? > > > > I also wouldn't want the fact that I'm listening on the device to > > interfere with sleep. Do I need to listen for system power > > notifications and close the port when the system is requesting > > permission to go to sleep? > > As with all BSDs, you should open the call-in device (/dev/tty*). > > Programs that want to use the line to call out will open the call-out > device (/dev/cu*) > > Typically, this means you open /dev/tty.modem, and others will open > /dev/cu.modem. > > Having the call-in device open should not prevent the system from > sleeping. > > = Mike > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: kernel panics and nvram issues
by Godfrey van der Linden 12 Feb '05

12 Feb '05

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Cheers Godfrey On Feb 9, , at 11:05, Garth Cummings wrote: Hi David, On Feb 9, 2005, at 10:21 AM, David Osguthorpe wrote: Anybody know if the kernel hooks in the IOKit for the NVRAM allow for the creation of such a program? Neither of these will affect when the kernel will next read NVRAM. It makes for difficult cluster management if you have to reboot the nodes just to udpate the nvram variables --gc __________________________________________________________________ Garth Cummings Apple Developer Technical Support gcummings(a)apple.com http://developer.apple.com/technicalsupport _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/gvdl%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Finally I might add that I have recently discovered the sysctl for allowing dynamic modification of boot arguments. This stuff is fairly easy to do, You may want to use bug-reporter to file an enhancement request. Are you guys building your own kernel? If so we may be able to work out a sysctl to allow the setting of the 'boot-args' in the kernels current state. On Tue, Feb 08, 2005 at 03:12:11PM -0800, Shantonu Sen wrote: You are most likely running the nvram(8) commandline tool and not rebooting. The core dumping settings will not be honored (they are only parsed at startup) and the settings will not be preserved. Is there no way to force the nvram update without rebooting? The issue is not that NVRAM requires a reboot to be changed. It doesn't. The NVRAM has indeed been updated once you've run the nvram command. The issue is that the kernel only reads the changed variables out of NVRAM at boot time. Is the NVRAM memory mapped into the kernel such that the bsd kvm_read/kvm_write calls can be used to update the NVRAM? A valid point. But if you've panicked, you have to reboot anyway. You can save one reboot by updating NVRAM using the Open Firmware UI, but that requires you to be physically present at the server. There are a few Technical Q&As showing how to update the config variables using the OFUI. David This email sent to gvdl(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0