Mail Delivery Problem
SMTP MAILER
postmaster at [unknown]
Wed Aug 29 23:34:17 AEST 1990
----Reason for mail failure follows----
Sending mail to host ise.ncsl.nist.gov :
Unrecognized host name or address.
----Transcript of message follows----
Date: 27 Aug 90 13:20:00 GMT+109:13
From: unix-wizards at BRL.MIL
Subject: UNIX-WIZARDS Digest V10#129
To: "barkley" <barkley at ise.ncsl.nist.gov>
Return-Path: <unixwiz-request at ecf.ncsl.nist.gov>
Received: from SEM.BRL.MIL by ecf.ncsl.nist.gov with SMTP ;
Mon, 27 Aug 90 13:19:58 EST
Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa02920; 27 Aug 90 5:54 EDT
Received: from sem.brl.mil by SEM.BRL.MIL id aa02873; 27 Aug 90 5:45 EDT
Date: Mon, 27 Aug 90 05:45:02 EST
From: The Moderator (Mike Muuss) <Unix-Wizards-Request at BRL.MIL>
To: UNIX-WIZARDS at BRL.MIL
Reply-To: UNIX-WIZARDS at BRL.MIL
Subject: UNIX-WIZARDS Digest V10#129
Message-ID: <9008270545.aa02873 at SEM.BRL.MIL>
UNIX-WIZARDS Digest Mon, 27 Aug 1990 V10#129
Today's Topics:
SUMMARY: Are pointers in a shared memory segment valid for a different process?
Re: UNIX does *not* fully support asynchronous I/O
Re: pty bugs & features
Named Pipe Portability??
Re: OK, so why _does_ ld resolve text against data?
Re: How to acknowledge a Password for a Daemon point of view ?
Re: pty bugs & features
How to write a Unix Shell?
Re: Session management
-----------------------------------------------------------------
From: Todd Kelley <kelley at qucis.queensu.ca>
Subject: SUMMARY: Are pointers in a shared memory segment valid for a different process?
Keywords: shared memory, pointers, IPC
Date: 25 Aug 90 19:52:08 GMT
To: unix-wizards at sem.brl.mil
This is a summary of responses to my question about pointers in
shared memory. I'd like to thank all those who provided a response:
volpe at disney.crd.ge.com (Christopher R Volpe)
Greg Hunt <hunt at DG-RTP.DG.COM>
Jean-Luc Lachance <jll at tnl.CAM.ORG>
Doug Luecke <iex!neptune.iex.com!doug at uunet.UU.NET>
mmcg at bruce.cs.monash.OZ.AU (Mike McGaughey)
Question:
>Suppose that process A and process B both have one particular shared
>memory segment attached to their respective address spaces with shmat().
>
>Now suppose that process A puts an array of strings into the shared memory
>segment, such that each string resides in the shared memory segment, but
>they do not occupy a contiguous piece of memory. That array will be
>meaningless to process B, because the (char *) pointers in the array
>point into A's address space, and not B's address space. If the base of
>the shared memory segment is at AAA0 in A's address space, and at
>BBB0 in B's address space (for example), in order for
>B to access the strings in the array, B would need to add (AAA0-BBB0) to
>each of the pointers in the array to make them point at the strings in
>B's address space.
>
>Is this wrong? If not, is there an accepted way to map addresses back
>and forth between address spaces? Should each string's offset from the
>base of the segment be stored in the array, rather than the actual pointer?
Almost everyone said that pointers to data in a shared memory segment
should be stored as an offset from the base of the segment. (The one
exception involved the assumption that the base of the segement would
be the same in both processes.) It was mentioned that arranging to
have a shared segment attached at the same address in both processes
can be attempted, but this becomes a problem if the application is handling
multiple shared segments of varying sizes.
Also, since offsets are integers, an array of strings would be stored
in a shared segment as an array of integers instead of "char *".
A macro could be used to convert an integer to the corresponding "char *",
for example, SHMOFF_TO_POINTER(segment, offset).
Below are two examples of C code. The first shows how to deal with
an array of strings in shared memory, and the second shows how to deal
with an array of structures in shared memory.
----------------------------------------------------------------------------
From: volpe at disney.crd.ge.com (Christopher R Volpe):
For example, you might do something along the lines of this:
char *string_one;
char *string_two;
int *string_pointer_offsets;
string_one= get_free_shmem_space(25*sizeof(char));
strcpy(string_one,"First string data");
string_two= get_free_shmem_space(25*sizeof(char));
strcpy(string_two,"Second string data");
string_pointer_offsets=get_free_shmem_space(2*sizeof(int));
string_pointer_offsets[0]=string_one-shmem_base;
string_pointer_offsets[1]=string_two-shmem_base;
Now, assuming you communicate to the other process where
"string_pointer_offsets"
is, or always keep it in some hard-coded predefined place in shared memory,
the other process can look at the two elements, add its own shmem_base
to each, and get at the data for string_one and string_two.
==================
Chris Volpe
G.E. Corporate R&D
volpecr at crd.ge.com
----------------------------------------------------------------------
From: Greg Hunt <hunt at DG-RTP.DG.COM>
This coupled with C's (I'm assuming that you're using C) pointer
arithmetic capabilities makes it very simple to move around [in] arrays in
shared memory. You compute the (base + offset to beginning of array)
once for each process and remember it in a global variable or
something. From then on you use C pointer arithmetic to access
elements of the array like this:
ptr_to_base_of_array = my_shared_segment_attach_address +
offset_of_array_into_segment;
To access any element use:
(ptr_to_base_of_array + element_number) -> structure_element ...
The element numbers are the the array subscripts as you would
normally use them. The first element being numbered zero, the last
one being numbered (number_of_elements_in_array - 1).
You need to properly cast the pointers into "pointers to an element
of the array" to get the pointer arithmetic to work properly.
That's my opinion on the matter. Hope this helps. Enjoy!
--
Greg Hunt Internet: hunt at dg-rtp.dg.com
DG/UX Kernel Development UUCP: {world}!mcnc!rti!dg-rtp!hunt
Data General Corporation
Research Triangle Park, NC These opinions are mine, not DG's.
-------------------------------------------------------------------------
--
Todd Kelley (kelley at qucis.queensu.ca)
-----------------------------
From: Eliot Moss <moss at cs.umass.edu>
Subject: Re: UNIX does *not* fully support asynchronous I/O
Date: 26 Aug 90 15:46:30 GMT
Sender: news at dime.cs.umass.edu
Followup-To: comp.lang.misc
To: unix-wizards at sem.brl.mil
Such extra support for multi-buffered asynchronous I/O is supported by DEC
under Ultrix for access to raw disk devices .... Eliot
--
J. Eliot B. Moss, Assistant Professor
Department of Computer and Information Science
Lederle Graduate Research Center
University of Massachusetts
Amherst, MA 01003
(413) 545-4206; Moss at cs.umass.edu
-----------------------------
From: Dan Bernstein <brnstnd at kramden.acf.nyu.edu>
Subject: Re: pty bugs & features
Date: 26 Aug 90 17:20:36 GMT
To: unix-wizards at sem.brl.mil
In article <3954 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
> >I would think this could be a problem with other drivers besides ptys.
> It could be. Unfortunately, just about *any* close behavior is going to
> screw *somebody*.
Not necessarily.
> Waiting forever for output to drain can lock up a tty port forever if it
> gets ^S'ed and there's output waiting.
This is the correct behavior. The difficulties with locking up tty ports
are reflections of two different problems: first, that ptys aren't
dynamically allocated in 4BSD; and second, that standard ttys exist at
all. Hardwired /dev/tty* should be replaced with raw /dev/modem* and so
on; *all* tty use should go through a common interface provided by a
pseudo-terminal session manager. This would solve many problems at once.
---Dan
-----------------------------
From: Robert Lin <rlin at cs.ubc.ca>
Subject: Named Pipe Portability??
Date: 26 Aug 90 19:18:21 GMT
Sender: news at cs.ubc.ca
To: unix-wizards at sem.brl.mil
I am trying to establish exactly how portable my program is, that uses
named pipes (i.e. mknod ("test.fifo", I_SFIFO | 0666, 0) call).
As far as I know, all V7, System III, System IV, SunOS will support
named pipes. According to Marc Rochkind, BSD 4.2 does NOT support
named pipes. My question is, does BSD 4.3 support named pipes? How common
is BSD 4.2, and which commercial machines are strictly BSD 4.2?
In particular, I'd like to find out if the following OS support name pipes:
1. Ultrix
2. AUX
3. AIX 3.0/3.1
4. HP/UX
5. Apollo's DomainOS
-----------------------------
From: Wayne Throop <throopw at sheol.uucp>
Subject: Re: OK, so why _does_ ld resolve text against data?
Date: 26 Aug 90 19:06:13 GMT
To: unix-wizards at sem.brl.mil
> From: das at eplunix.UUCP (David Steffens)
> Said shared name space extends beyond the confines of _my_ code, however.
> And that makes it a linker problem, _not_ a compiler problem.
I disagree most strenuously. The compiler is the agent that "decided"
to name things that should definitely not be resolved together with
the same name. The linker advertises what it will do with its namespace,
and the compiler decides to name two incompatible things with the
same linker name. I think it quite clear that the compiler is at fault.
One may object that the compiler is merely naming the entity with the
name given it in the source code. But this just isn't (normally) so,
even (or maybe especially) in C. In fact, it is common to play games
with the link-time names of things. Fortran, for example, twiddles with
case, C prepends a superfluous "_". And more recent C++ implementations
choose names which reflect the type of the link-time object generated.
So, if the compiler would simply tag things with link-time names which
reflect the distinctions that should be made, the link will do the right
thing, and can even produce intelligible source-level error messages
if it is made privy to some backtranslation database.
--
Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw at rti.rti.org
-----------------------------
From: Kim Christian Madsen <kimcm at diku.dk>
Subject: Re: How to acknowledge a Password for a Daemon point of view ?
Keywords: password dameon
Date: 26 Aug 90 23:06:08 GMT
To: unix-wizards at sem.brl.mil
rickert at mp.cs.niu.edu (Neil Rickert) writes:
>In article <1990Aug25.025441.18302 at diku.dk> I wrote:
>>1) Read the encrypted password from the password file and store it in
>> a variable, store the user typed password in another variable and
>> use the function below:
>>
>> int authenticate(crypt_pw,typed_pw)
>> char *crypt_pw, *typed_pw;
>> {
>> char salt[2];
>> extern char *crypt();
>>
>> (void) strncpy(salt,crypt_pw,2);
>> return(strcmp(crypt_pw,crypt(typed_pw,salt)) == 0);
>> }
> What is wrong with skipping 'salt[2]' and the strncpy, and using:
> return(strcmp(crypt_pw,crypt(typed_pw,crypt_pw)) == 0);
Well, nothing is wrong with skipping the salt, except that I find your
solution confusing if you compare it with the manual entry for
crypt(3C) and the formal parameter declaration of crypt(). Granted, my
solution uses an extra function call, the strncpy(), and two extra
bytes on the stack, but if tight optimizing or conservation of stack
usage isn't called for I prefer to use more describing/understanable
code, instead of rigid optimized code. Incidently I think the most
terse code will result from:
return(!strcmp(crypt_pw,crypt(typed_pw,crypt_pw)));
As Always, Best Regards
Kim Chr. Madsen
kimcm at diku.dk
-----------------------------
From: Boyd Roberts <boyd at necisa.ho.necisa.oz>
Subject: Re: pty bugs & features
Date: 27 Aug 90 01:37:19 GMT
To: unix-wizards at sem.brl.mil
In article <3954 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
>
>It could be. Unfortunately, just about *any* close behavior is going to
>screw *somebody*.
>
This is the _classic_ `virtual circuit problem'. The problem of
deciding what is circuit shutdown [error] and what is end of data,
and which is appropriate. You've got to make _all_ the right choices,
and some of them are _hard_.
The way I like to think about it is the way pipes work. A close
on a pipe indicates EOF to the reader. But, a write on a pipe
with no one to read it is an error (SIGPIPE/EPIPE). But, to
generalise this correctly you need to be able to say `kill this
circuit for me because an error's occurred', so that one
end can say to the other that somethings up.
I say that each protocol layer should be self contained and _clean_.
Now, the ISO people are not going to like this, but with virtual
circuits you require two ways to shutdown a circuit at the protocol
level itself, and not make it the responsibility of the layer above.
I remember all too well the existential horror when I realised (while
writing this X.25 `spool across the wire' print server/client) that
when I said close() it shut the circuit down -- _right now_!! No
waiting for the data to arrive at the other end -- nothing. I had
to write this _revolting_ gore, using the Q bit to say:
X.25 software ABC X.25 software DEF
Client: write(You got that?|Q_BIT)
Server: read() You got that?|Q_BIT
Server: write(I got it|Q_BIT)
Server: hangup circuit after `I got it'
is delivered
Client: read() I got it|Q_BIT
Client: close() Server: close()
Client: exit() Server: Loop
I didn't want to write any file transfer protocol -- why should I? After
all, I was using a reliable, sequenced, unduplicated, connection based
virtual circuit. I just wanted close() to block correctly and for a
subsequent server read() to return 0. But, X.25 software ABC had an
`interesting' idea about virtual circuits.
So I got to thinking that this was just _wrong_ and that Dennis* did it right.
Boyd Roberts boyd at necisa.ho.necisa.oz.au
``When the going gets wierd, the weird turn pro...''
* pure, vanilla, no foul gore, straight streaming V8 stream code
-----------------------------
From: Doug Gwyn <gwyn at smoke.brl.mil>
Subject: Re: pty bugs & features
Date: 27 Aug 90 05:29:06 GMT
To: unix-wizards at sem.brl.mil
In article <6038 at muffin.cme.nist.gov> libes at cme.nist.gov (Don Libes) writes:
>Why do pty's return EIO instead of 0 upon EOF?
If they do this, it is clearly wrong and would most likely be due to
UNIX development now being done, or at least directed, by people who
don't understand UNIX. read() should not return -1 upon encountering
normal EOF on ANY object. If the end of the stream is due to a
communication link failure, for example, then an error indication
would in fact be preferable to an undifferentiated EOF indication.
>Why do stream's dump their buffers when the writer closes?
They're not supposed to; do they really do that? Is USO really
screwing up UNIX to such an extent??
>What is it you are expected to do in 15 seconds?
There is no justification for penalizing an application for not
consuming all the data buffered in the kernel within 15 seconds.
I lost track of the origin of this thread; if this timeout is supposed
to be related to the TCP protocol, my guess would be that somebody has
yet again tripped up on the "FIN_WAIT_2" issue.
>And finally, why does everyone answer easy questions with "[long essay
>deleted] and this should probably be in the FAQ if it isn't already"?
>That indicates to me that neither the asker nor the answerer has read
>the FAQ.
Not really, usually it indicates that the responder has not memorized
the FAQ list but feels that the question should be there and that either
the asker has failed to read the FAQ list or else the question wasn't
there. (Or, as in in your case,
>... at the moment ... the FAQ has slipped off the face of the earth.
)
-----------------------------
From: Tom Armistead <toma at ozdaltx.uucp>
Subject: How to write a Unix Shell?
Keywords: ksh, sh, csh, bash
Date: 27 Aug 90 02:24:03 GMT
To: unix-wizards at sem.brl.mil
Does anyone know where I can find any information on how to write a Unix
command shell (like sh or ksh)?
I have access to ksh and bash source, but don't want to spend the rest of
my life trying to figure those out.
I would like to find out how the environment space is handled. What, if
anything, needs to be done to siatisfy the kernel and/or the C library
functions like getenv(), putenv() and popen(). And probally a few million
other things that I haven't thought of.
Just to answer any "How come?" questions. "I don't have any real reasons,
just thought it might be fun..."
Any help would be greatly appreciated!!!
Tom
--
-------------------------------
{uunet,smu,ames}!sulaco!ozdaltx!toma (Tom Armistead @ Garland, Texas)
{mic,void,egsner}!ozdaltx!toma
-----------------------------
From: Tom Christiansen <tchrist at convex.com>
Subject: Re: Session management
Keywords: pty login daemon session
Date: 27 Aug 90 02:33:22 GMT
Sender: news at convex.com
To: unix-wizards at sem.brl.mil
In article <8319:Aug2617:20:3690 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>This is the correct behavior. The difficulties with locking up tty ports
>are reflections of two different problems: first, that ptys aren't
>dynamically allocated in 4BSD; and second, that standard ttys exist at
>all. Hardwired /dev/tty* should be replaced with raw /dev/modem* and so
>on; *all* tty use should go through a common interface provided by a
>pseudo-terminal session manager. This would solve many problems at once.
I think there is a crying need such a thing because the same code gets
written again and again to do essentially the same thin How would you like
to see a pty session manager work? I'm going to throw out some
off-the-cuff ideas, plus a lot of for-thought questions, to see what the
net thinks.
I'd like to solve at least these problems:
1. getting the pty name right (varies system to system)
2. race condition between choosing a name and trying the open
3. the need to be suid to get a pty
4. the need to chown the pty appropriately
5. the need to properly update utmp and wtmp
Many programs (script, window, xterm) would no longer need to be
setuid to munge utmp or chown ptys, which would be a nice plus.
Off the top of my head, here are some ideas that are implementable on a
BSD system.
I would make a daemon server that everyone talked to in order to get
the session. You could instead put it in the kernel as a special
"/dev/pty" pseudo-driver that did the allocation for you, but I don't
see much that having it in the kernel might gain you considering
the cost.
How might it actually work?
If we used a UNIX-domain UDP socket, we could pass file descriptors
between processes. Let the daemon do all the work of finding, opening,
and chowning the pty, plus the [wu]tmp munging. He could just call
if (getpty(&master_fd, &slave_fd) != -1) {
and have the fd's filled in. Would we want to know the name? If so,
we could something like this do this:
if ((ptyname = getpty(&master_fd, &slave_fd)) != (char *)0) {
You say, but wait, you might want to be able to make this work for remote
logins, so I can't use UNIX domain sockets. Perhaps this is a valid
point: if we did that, could we get rid of rlogind, telnetd, Then how
would the file-descriptor hand-off take place? What about urgent data and
stderr? Can the pty model really be adopted to the socket and connect
method? Since telnet, rlogin, DECNET-style sethost, and Sun's "on -i"
program all use different protocols, I suspect this is infeasible. Maybe
we better leave it as is and keep and rlogind and friends around, but this
is mildly unsettling.
How would the daemon know that when the pty was free so that it could
return the pty to the free pool and fix up utmp and wtmp?
Rlogind knows because the login process is his child whom he waits on, but
the session manager deals with unrelated processes. If the function were
to actually spawn a login-shell on a pty, then it could wait for the kid
to do the cleanup, but that sort of behavior wouldn't always be
appropriate.
If we placed it in the kernel, I supposed the close routine could know to
do the right thing, but I wouldn't like to have the kernel mucking with
[wu]tmp files. Maybe a stronger interaction with the kernel, as in Suns'
lock daemon and its kernel RPC calls.
Do you ever NOT want an entry in utmp? Sometimes ptys are used to run
processes that just want a tty but aren't really a login session. Should
they be? xterm (sometimes) and emacs don't currently put lines there, but
I'm not sure whether this is a feature or not. If we really wanted it, we
could have either two entry points or else an extra parameter.
Could this be made to work using non-BSD systems? Would it eventually
go in a POSIX spec, and if so, which one? Certainly system calls and
library functions, but what of networking or system administration?
Has this been done yet? Attempted? Contemplated?
--tom
--
"UNIX was never designed to keep people from doing stupid things, because
that policy would also keep them from doing clever things." [Doug Gwyn]
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.internals
mailing list