Date: Wed, 24 Nov 2004 00:04:18 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 456 ************************************************** Tuesday 23 November 2004 Number 456 ************************************************** Subjects for today 1 Re: GCC v3.3.5 / LIBC v0.6 - Alpha 3 : Steve Wendt 2 Re: No controlling tty : John Poltorak 3 setsid() ?? : Paul Smedley" 4 Re: setsid() ?? : John Poltorak 5 Re: System V Semaphore emulation : Andrew MacIntyre 6 Re: System V Semaphore emulation : lsunley at mb.sympatico.ca 7 setitimer implementation : lsunley at mb.sympatico.ca 8 Re: setsid() ?? : Paul Smedley 9 Re: setsid() ?? : John Poltorak 10 Network Time Protocol : John Poltorak 11 Re: Network Time Protocol : John Poltorak 12 Re: System V Semaphore emulation : Andrew MacIntyre 13 Re: Network Time Protocol : Henry Sobotka **= Email 1 ==========================** Date: Mon, 22 Nov 2004 12:41:10 -0800 (PST) From: Steve Wendt Subject: Re: GCC v3.3.5 / LIBC v0.6 - Alpha 3 On Mon, 22 Nov 2004, Knut St. Osmundsen wrote: > I will change my code to use the same EAs as the linux hpfs vfs module. Thanks! **= Email 2 ==========================** Date: Mon, 22 Nov 2004 21:04:47 +0000 From: John Poltorak Subject: Re: No controlling tty On Mon, Nov 22, 2004 at 01:54:36PM +0100, Knut St. Osmundsen wrote: > > If I'm reading the code correctly, it's a warning only - so does pdksh work, > > or does it not work? If it does already work, modifying the above code > > snippet is probbly enough to silence the warning, if it does not, then Innotek's > > libc apparently doesn't emulate terminals/pseudo terminals the way EMX did - and > > there's a major problem. > > IIRC EMX implements /dev/tty. LIBC doesn't do that yet. I'm not sure > what the requirements for getting that working 100% are, and it's gonna > take some time investigating it. I ran into the concept of controlling > tty while looking at process groups / job control / signals but haven't > had time to delve into all the details yet. > > Any help on the subject would be appreciated, especially if it includes > code. :-) There is source in each of these which handles /dev/tty:- emx\src\os2\fileio.c emx\src\lib\sys\open.c emx\src\dos\syscall.asm /* Interpret "/dev/null" and "/dev/tty" as the name of the null device "NUL" or of the console "CON", respectively. Copy the path name to `fname', with modifications according to the -r and -t options. */ is_pty = FALSE; if (strcmp (path, "/dev/null") == 0) strcpy (fname, "nul"); else if (strcmp (path, "/dev/tty") == 0) strcpy (fname, "con"); else if (!(debug_flags & DEBUG_NOXF86SUP) && IS_PTY_NAME (path)) { is_pty = TRUE; strcpy (fname, path); } else truncate_name (fname, path); > Kind Regards, > knut -- John **= Email 3 ==========================** Date: Tue, 23 Nov 2004 07:28:25 +1000 From: "Paul Smedley" Subject: setsid() ?? I'm trying to update a build I did a few years back of bpalogin (bpalogin.sourceforge.org) which is a Cable Internet login client for Telstra Bigpond in Australia. Why is their a login client for cable internet - don't go there :) for some reason - instead of using the MAC address of the cable modem to authenticate - Telstra chose to implement a login client!! Anyway, am building with UX2BS - configure ran fine, ran make - got errors due to missing syslog.h - thought this would have been in /include already but wasn't... copied over syslog.h, syslog.a & syslog.lib from my EMX setup - added -lsyslog to makefile and now stuck with setsid() Whilst I'm tempted just to comment out the setsid code from below - is there a 'standard' workaround for this? Thanks, Paul. if(makedaemon) { /** * Original code did not perform the setsid() or second fork(), and * hence did not correctly make itself a daemon. There is a library * call in FreeBSD (daemon) that does the actions below, but the * portability is unknown. */ switch( fork() ) { case 0: break; case -1: perror("Could not run BPALogin in the background"); exit(1); break; default: exit(0); break; } if( setsid() < 0 ) { perror("Could not run BPALogin in the background"); exit(1); } /** * while not strictly necessary, the second fork ensures we stay * detached from a terminal by preventing the program using its * status as session leader to regain a terminal. */ switch( fork() ) { case 0: break; case -1: perror("Could not run BPALogin in the background"); exit(1); break; default: exit(0); break; } } **= Email 4 ==========================** Date: Mon, 22 Nov 2004 23:08:10 +0000 From: John Poltorak Subject: Re: setsid() ?? On Tue, Nov 23, 2004 at 07:28:25AM +1000, Paul Smedley wrote: > I'm trying to update a build I did a few years back of bpalogin > (bpalogin.sourceforge.org) which is a Cable Internet login client for > Telstra Bigpond in Australia. > > Why is their a login client for cable internet - don't go there :) for > some reason - instead of using the MAC address of the cable modem to > authenticate - Telstra chose to implement a login client!! > > Anyway, am building with UX2BS - configure ran fine, ran make - got > errors due to missing syslog.h - thought this would have been in > /include already but wasn't... copied over syslog.h, syslog.a & > syslog.lib from my EMX setup - added -lsyslog to makefile and now stuck > with setsid() Which UX2BS did you use? I just tried it and it build fine - apart from needing to run EMXBIND at the end, but that could be sorted out with the appropriate *FLAGS... I don't know anything about the program but here's what it does when I run it:- U:\ux2bs\workdir\bpalogin-2.0.1>bpalogin.exe BPALogin v2.0 - lightweight portable BIDS2 login client Copyright (c) 1999-2000 Shane Hyde (shyde at trontech.net) This program is *not* a product of Big Pond Advance Usage: bpalogin [options], where options are: -c conffile Specifies the config file to read option settings from (default is /etc/bpalogin.conf) -D Dont run bpalogin as a daemon (run in foreground) Note that command line options override the values in the conffile -- John **= Email 5 ==========================** Date: Tue, 23 Nov 2004 08:11:27 +1100 (EST) From: Andrew MacIntyre Subject: Re: System V Semaphore emulation On Mon, 22 Nov 2004, Knut St. Osmundsen wrote: > Sys V sems means semctl(), semget(), semop(), right? If so, that's on > the todo list for LIBC. If someone have some half decent code for this, > please tell me. Same goes for the the simple shared memory interface > (not the one using filehandles and mmap). The big trap with these, as far as I understand, is that they are persistent - ie they survive after all referencing processes die, and can be picked up later by new processes. This applies to the Sys V shared memory (shm*()) and message queues as well. What I've read of the CP docs suggest to me that OS/2's semaphores and shared memory don't match these semantics, disappearing after the last referencing process dies. Venuto's implementation uses a daemon process to implement these semantics on OS/2; FreeBSD & Solaris use kernel modules (Linux may do this too). ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac at pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 6 ==========================** Date: Mon, 22 Nov 2004 18:54:25 -0500 From: lsunley at mb.sympatico.ca Subject: Re: System V Semaphore emulation In <20041123080228.H30060 at bullseye.apana.org.au>, on 11/23/04 at 08:11 AM, Andrew MacIntyre said: >On Mon, 22 Nov 2004, Knut St. Osmundsen wrote: >> Sys V sems means semctl(), semget(), semop(), right? If so, that's on >> the todo list for LIBC. If someone have some half decent code for this, >> please tell me. Same goes for the the simple shared memory interface >> (not the one using filehandles and mmap). >The big trap with these, as far as I understand, is that they are >persistent - ie they survive after all referencing processes die, and can >be picked up later by new processes. This applies to the Sys V shared >memory (shm*()) and message queues as well. >What I've read of the CP docs suggest to me that OS/2's semaphores and >shared memory don't match these semantics, disappearing after the last >referencing process dies. >Venuto's implementation uses a daemon process to implement these >semantics on OS/2; FreeBSD & Solaris use kernel modules (Linux may do >this too). I have some code for semctl(), semget(), semop() that is implemented using Event semapores and DosCreateMuxWaitSem for multiple semaphore waits. There is some stuff that has to be done for signals (ctrl-C, ctrl-Break) that have to terminate the wait. All of this is untested at present. I think it will be some time (2 weeks) before I know if it works right. I was just letting unreferenced semaphores die a natural death, and reporting that they no longer exist if requested as that is what the win32 implementation for postgreSQL seems to do. The postgreSQL code seems to kill off left over semaphores and shared memory regions if they are left over from a process that died. It seems that leaving them for the OS/2 kernel to kill off would be a good thing. Lorne -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 7 ==========================** Date: Mon, 22 Nov 2004 21:46:19 -0500 From: lsunley at mb.sympatico.ca Subject: setitimer implementation Hi All In the new GCC335 the sys\time.h header has a prototype for setitimer, unfortunately there does not appear to be am implementation of the actual code. Is there one somewhere?, or maybe due in a later release of LIBC? It is yet another thing required by postgreSQL Lorne -- ----------------------------------------------------------- lsunley at mb.sympatico.ca ----------------------------------------------------------- **= Email 8 ==========================** Date: Tue, 23 Nov 2004 16:41:46 +1030 From: Paul Smedley Subject: Re: setsid() ?? Hi John, John Poltorak wrote: > On Tue, Nov 23, 2004 at 07:28:25AM +1000, Paul Smedley wrote: > >>I'm trying to update a build I did a few years back of bpalogin >>(bpalogin.sourceforge.org) which is a Cable Internet login client for >>Telstra Bigpond in Australia. >> >>Why is their a login client for cable internet - don't go there :) for >>some reason - instead of using the MAC address of the cable modem to >>authenticate - Telstra chose to implement a login client!! >> >>Anyway, am building with UX2BS - configure ran fine, ran make - got >>errors due to missing syslog.h - thought this would have been in >>/include already but wasn't... copied over syslog.h, syslog.a & >>syslog.lib from my EMX setup - added -lsyslog to makefile and now stuck >>with setsid() > > > Which UX2BS did you use? Yours - built in September. > I just tried it and it build fine - apart from needing to run EMXBIND at > the end, but that could be sorted out with the appropriate *FLAGS... > > > I don't know anything about the program but here's what it does when I run > it:- > > U:\ux2bs\workdir\bpalogin-2.0.1>bpalogin.exe > BPALogin v2.0 - lightweight portable BIDS2 login client > Copyright (c) 1999-2000 Shane Hyde (shyde at trontech.net) That's old source - current source is 2.0.2 from http://bpalogin.sourceforge.net/download/bpalogin-2.0.2.tar.gz It used to build fine (the OS/2 build at sourceforge is from me). I get: unixmain.c:220 (unixmain.o): Undefined symbol _setsid referenced from text segment Cheers, Paul. **= Email 9 ==========================** Date: Tue, 23 Nov 2004 10:03:56 +0000 From: John Poltorak Subject: Re: setsid() ?? On Tue, Nov 23, 2004 at 04:41:46PM +1030, Paul Smedley wrote: > > I don't know anything about the program but here's what it does when I run > > it:- > > > > U:\ux2bs\workdir\bpalogin-2.0.1>bpalogin.exe > > BPALogin v2.0 - lightweight portable BIDS2 login client > > Copyright (c) 1999-2000 Shane Hyde (shyde at trontech.net) > That's old source - current source is 2.0.2 from > http://bpalogin.sourceforge.net/download/bpalogin-2.0.2.tar.gz It's odd that I managed to pick up an old version from Sourceforge, but I have the update now and do get the same error as you regarding setsid() but no problem with missing syslog.h... > It used to build fine (the OS/2 build at sourceforge is from me). > > I get: > unixmain.c:220 (unixmain.o): Undefined symbol _setsid referenced from > text segment Looking through \unixos2\posix2\lib\cExt.lib I do see a reference to setsid - maybe Stefan can shed some light on whether it should get picked up by make.. > Cheers, > > Paul. -- John **= Email 10 ==========================** Date: Tue, 23 Nov 2004 10:27:13 +0000 From: John Poltorak Subject: Network Time Protocol Is there an OS/2 port of the Network Time Protocol daemon? NTP is one of the most important programs on the Internet and it would be nice to get it to build on OS/2. It would also show how Posix compliant OS/2 can be. If anyone wants to have a look at it, the source is here:- ftp://ftp.udel.edu/pub/ntp/ntp4/ntp-4.2.0.tar.gz The NTP home page - http://www.ntp.org is quite interesting in itself. -- John **= Email 11 ==========================** Date: Tue, 23 Nov 2004 12:00:48 +0000 From: John Poltorak Subject: Re: Network Time Protocol On Tue, Nov 23, 2004 at 10:27:13AM +0000, John Poltorak wrote: > > Is there an OS/2 port of the Network Time Protocol daemon? > > NTP is one of the most important programs on the Internet and it would be > nice to get it to build on OS/2. It would also show how Posix compliant > OS/2 can be. > > If anyone wants to have a look at it, the source is here:- > > ftp://ftp.udel.edu/pub/ntp/ntp4/ntp-4.2.0.tar.gz I gave it a try and here's what happened? Making all in libntp make[2]: Entering directory `U:/ux2bs/workdir/ntp-4.2.0/libntp' source='systime.c' object='systime.o' libtool=no \ depfile='.deps/systime.Po' tmpdepfile='.deps/systime.TPo' \ depmode=gcc u:/bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../include -Wall -Wcast-qual -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -c `test -f 'systime.c' || echo './'`systime.c In file included from ..\include\ntp_fp.h:10, from systime.c:8: ...\include\ntp_rfc2553.h:177: redefinition of `struct sockaddr_storage' systime.c: In function `adj_systime': systime.c:139: warning: implicit declaration of function `adjtime' make[2]: *** [systime.o] Error 1 make[2]: Leaving directory `U:/ux2bs/workdir/ntp-4.2.0/libntp' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `U:/ux2bs/workdir/ntp-4.2.0' make: *** [all] Error 2 Any clues about what is at fault? -- John **= Email 12 ==========================** Date: Tue, 23 Nov 2004 22:27:33 +1100 (EST) From: Andrew MacIntyre Subject: Re: System V Semaphore emulation On Mon, 22 Nov 2004 lsunley at mb.sympatico.ca wrote: > In <20041123080228.H30060 at bullseye.apana.org.au>, on 11/23/04 > at 08:11 AM, Andrew MacIntyre said: > > >On Mon, 22 Nov 2004, Knut St. Osmundsen wrote: > > >> Sys V sems means semctl(), semget(), semop(), right? If so, that's on > >> the todo list for LIBC. If someone have some half decent code for this, > >> please tell me. Same goes for the the simple shared memory interface > >> (not the one using filehandles and mmap). > > >The big trap with these, as far as I understand, is that they are > >persistent - ie they survive after all referencing processes die, and can > >be picked up later by new processes. This applies to the Sys V shared > >memory (shm*()) and message queues as well. > > >What I've read of the CP docs suggest to me that OS/2's semaphores and > >shared memory don't match these semantics, disappearing after the last > >referencing process dies. > > >Venuto's implementation uses a daemon process to implement these > >semantics on OS/2; FreeBSD & Solaris use kernel modules (Linux may do > >this too). > > I have some code for semctl(), semget(), semop() that is implemented using > Event semapores and DosCreateMuxWaitSem for multiple semaphore waits. > There is some stuff that has to be done for signals (ctrl-C, ctrl-Break) > that have to terminate the wait. All of this is untested at present. I > think it will be some time (2 weeks) before I know if it works right. > > I was just letting unreferenced semaphores die a natural death, and > reporting that they no longer exist if requested as that is what the > win32 implementation for postgreSQL seems to do. In the context of PostgreSQL this is probably Ok - I was pointing out the general semantics of these functions (as would be appropriate for a LIBC implementation). > The postgreSQL code seems to kill off left over semaphores and shared > memory regions if they are left over from a process that died. It seems > that leaving them for the OS/2 kernel to kill off would be a good thing. If the postmaster can identify junk and clean it up, so much the better. While its frequently useful for the OS to automatically clean up, sometimes its useful for the resources to be left around for later reuse and the Sys V IPC functions have the semantics to support this, in the same way that a named pipe or AF_UNIX socket can be left around (on Unix like OSes) for later reuse. ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac at pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 13 ==========================** Date: Tue, 23 Nov 2004 07:28:14 -0500 From: Henry Sobotka Subject: Re: Network Time Protocol John Poltorak wrote: > Is there an OS/2 port of the Network Time Protocol daemon? KUR's daytime package. Ancient, but should be on Hobbes. h~