HDTenEightyP/NetNews huggingface dataset:
From: Frank.ODwyer@sniap.mchp.sni.de ()
Subject: Re: RPC questions?
Organization: Siemens-Nixdorf AG
Date: Mon, 6 Apr 92 16:04:29 GMT

subbarao@phoenix.Princeton.EDU (Kartik Subbarao) writes:
: In article <1992Apr2.111313.9528@sniap.mchp.sni.de> Frank.ODwyer@sniap.mchp.sni.de writes:
: 
: >This is sounding more and more like the assembly language vs. HLL
: >debate.   Why do people hate technology which simplifies things?
: 
: This sounds like yet another sweeping generalization made on the net. Who
: said I "hated" technology which simplifies things? 

Who said anything about you?    I asked why *people* hated simplifying
technology (not saying that you're not a person :-) ).   It's true -
look at the DOS world's reaction to the Apple Mac & Windows.  Some people
cannot stand the idea that their 'special' knowledge will be made accessible
and usable by 'the rest of us'.    And the argument is always, but
always, so-called efficiency...

: My hesitation to plunge into threads with rpc is "Am I introducing levels of 
: complexity that I don't need"? It depends on how important the performance is 
: and how closely I want to be able to deal with data.

The idea of RPC as I see it is to do away with levels of complexity
which we don't need.    The arguments for using it are compelling and
go beyond just ease of use,  however.  (How about free security
and name service for a kick-off).  Most of us will use it, most of
the time.


--
----------------------------------------------------------------------------
Frank O'Dwyer, Siemens Nixdorf Munich   |    Disclaimer: 
Frank.ODwyer@sniap.mchp.sni.de          |    I will deny everything
----------------------------------------------------------------------------
From: pgd@compuram.bbt.se (Per Lindqvist)
Newsgroups: comp.unix.internals
Subject: Re: swap space
Date: 4 Apr 92 11:56:52 GMT

grog@adagio.UUCP (Greg Lehey) writes:
: As has been said, swapping from the swap space is not faster than
: swapping from the text file. Swapping unmodified pages *out* is
: brain-dead, and definitely slower than not swapping them out.

This is true only if the "text file" is not fragmented. If it is
fragmented it might be faster to write it to the (unfragmented) swap
space.  It also depends on where the text file is. If it is on
networked drive, it is also probably faster to write it to swap.
It also depends on the size. If the file is small, it might be faster
to read both text and data to swap, instead of reading text, seeking,
reading data.

-- 
Per Lindqvist

Internet: pgd@compuram.bbt.se   Fidonet: Per Lindqvist @ 2:201/332
Newsgroups: comp.unix.internals
From: jerryl@is.morgan.com (Jerry Liebelson)
Subject: How can I reliably determine the amount of real memory installed?
Keywords: memory
Organization: Morgan Stanley & Company, Inc.
Date: Tue, 14 Apr 1992 16:44:23 GMT

I want an accurate, reliable way to know the total amount of real memory
installed in a machine. I know that /usr/etc/dmesg or reading
/var/adm/messages will tell me this but only if the bootup message is
still there, otherwise what can I do?

ENVIRONMENT: Sun SparcStations, SunOS 4.11

Please email replies. Thanks.
-- 
o-----------------------------------------------------------------------------o
{  JERRY LIEBELSON                Email: jerryl@is.morgan.com                 }
{  Morgan Stanley & Co., Inc.            uunet!is.morgan.com!jerryl           }
{  1633 Broadway 36th Floor              Compuserve: 73477,2740               }
{  New York, NY  10019            Voice: (212) 703-2409   Fax: (212) 703-2371 }
o-----------------------------------------------------------------------------o
From: thomson@hub.toronto.edu (Brian Thomson)
Newsgroups: comp.unix.internals
Subject: Re: lseek(..., SEEK_END) behaviour
Keywords: lseek holey file
Date: 16 Apr 92 22:39:52 GMT
Organization: University of Toronto

In article <1992Apr16.091643.18604@west.nl> gertjan@west.nl (Gertjan van Oosten) writes:
>The following behaviour occurs under SunOS (both 4.0 and 4.1):
>
>If I seek beyond EOF [with lseek(..., SEEK_END)], and do it again, the
>second lseek() does not seek from the last seek position, but from the last
>written byte [example program below].
> that SunOS, 4BSD and SVID mention holes, X/Open does not.]
>
>What I want to know is:
>  a. Do you consider this behaviour correct (w.r.t. the man-page)?
>  b. Do you want this behaviour?
>
>My personal opinion:
>  ad a. This depends on the definition of 'the size (or length) of a file';
>        I don't want to answer that one...

Yes, I consider it correct.
The seek pointer is not part of the file.  It is simply a number, associated
with an opening of the file, and which forms an implicit parameter of any
succeeding read or write operation, that the system is kind enough to
update for you.  Changing it does not alter the file.  In particular,
it does not move the file end.

>  ad b. I don't; I'd like to see lseek() move from the last position (but
>        you already guessed that).

For this purpose you have SEEK_CUR.
-- 
		    Brian Thomson,	    CSRI Univ. of Toronto
		    utcsri!uthub!thomson, thomson@hub.toronto.edu
Newsgroups: comp.unix.internals
From: thurlow@convex.com (Robert Thurlow)
Subject: Re: How to know if file is on NFS filesystem?
Keywords: NFS
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Date: Mon, 13 Apr 1992 18:17:07 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

In <1992Apr10.093649.25729@bohra.cpg.oz.au> mike@bohra.cpg.oz.au (Mike Crooks) writes:

>There's actually a field in the structure returned by statfs() which holds the
>file system type.

Even better is that on Sun-based systems, statfs(2) is nice enough to
return the right information about any path you give it - the path need
not be the root of a file system.  This isn't universal, but it's sure
nice.

One more caveat is that you're screwed if the file server goes down.
If the file is mounted soft, you'll get an error from the call, but
if it's mounted hard, you will simply hang, hopefully interruptibly
so that you can get eventual control of the program again.  This is
ugly, but it's hard to avoid.

>The trouble is there is no standard usage - for example:

> HP UX (800 series):        f_fsid[1] == MOUNT_NFS

> Risc/Ultrix:               fd_req.fstype == GT_NFS

> AIX:                       f_fsid.val[1] == MNT_NFS

We do it too, and yet another way:

SunOS and ConvexOS:          f_type == MOUNT_NFS

Yes, we need to have everyone solve this in the same way for it to be
as useful as it could be.

Rob T
--
Rob Thurlow, thurlow@convex.com
Dreams are nothing more than wishes,
and a wish is just a dream you wish to come true	- Harry Nilsson
From: vsp@hpcupt3.cup.hp.com (V Shankar Prasad)
Date: Tue, 14 Apr 1992 00:27:37 GMT
Subject: Re: errno questions
Organization: Hewlett Packard, Cupertino
Newsgroups: comp.unix.internals

/ hpcupt3:comp.unix.internals / jik@athena.mit.edu (Jonathan I. Kamens) /  1:10 pm  Apr  9, 1992 /
>In article <etxaax.702829519@falcon2> etxaax@falcon2.ericsson.se (Anders Axelsson) writes:
>
>   Does anyone know if errno can be 0 after a Unix error?
>
>Define "Unix error."
>
>Do you mean, "An error in a UNIX system call whose documentation
>claims that it sets errno when an error occurs?"  Or do you mean, "An
>error in any UNIX library function?"
>
>No system call or function which claims to set errno when an error
>occurs should be setting it to 0.  If you check errno and find
>it equal to 0, it can mean one of several things:
>
>1) You're using errno when you shouldn't be, e.g. after calling a
>function which does not claim to set errno upon error.
>
>2) There is a bug in the system call or function you're calling -- it
>forgot to set errno when it should have.
>
>3) The system call or function knows that an error occurred, but it
>doesn't think that any of the errors in <errno.h> are an adequate
>description of the error, so it resorts to leaving 0 in errno.
>(Actually, I've never actually seen this happen, so I don't know if
>it's considered "OK" or not; I'm just postulating.)
>
>   sys_errlist[0] does
>   have a value, a cryptic message "Error 0".
>
>This is to deal with problems of the type (3) listed above, and also
>to deal with people doing bogus things like using sys_errlist[errno]
>or perror() when errno hasn't been set properly.

Isn't there a fourth situation ?  Checking errno when the system call
has not failed.  It must be kept in mind that checking errno is valid
only if the most recent system call (which claims to set errno) has
failed.  Checking for "errno == 0" to indicate success of the system
call is Bad (tm).
>
>   [two copies of signature]
>
>Tsk, tsk.
>
>-- 
>Jonathan Kamens						jik@MIT.Edu
>MIT Information Systems/Athena		    Moderator, news.answers
>    (Send correspondence related to the news.answers newsgroup
>	{and ONLY correspondence related to the newsgroup}
>		 to news-answers-request@MIT.Edu.)
>----------

Shankar Prasad
vsp@cup.hp.com
Xref: sparky comp.unix.internals:1068 comp.unix.sysv386:8238
From: sblair@upurbmw.dell.com (Steven C. Blair "Unix Network Services")
Newsgroups: comp.unix.internals,comp.unix.sysv386
Subject: Re: swap space
Date: 6 Apr 92 22:42:35 GMT
Organization: Dell Computer UNIX Internetworking Services

In article <ku1eeuINNlr2@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
> In article <1992Apr6.035620.8674@wndrsvr.la.ca.us> andyb@wndrsvr.la.ca.us (Andy Brager) writes:
> >pavlov@niktow.canisius.edu (Greg Pavlov) writes:
> >>   Our "rule of thumb" ratio, based on failures in the past, is 3:1 .  The 
> >>   "standard" recommendation that I see is usually 2:1 .
> 
the ratio is more historic than anything else. Especially true when in
the older days we had user environments that we didn't understand how
B-I-G things would get. Now adays, much more understanding of what the
machine ultimately will be tasked for upfront alleviates this confusion later.


Heck, I've got user that can eat up 8x RAM, before their machines give
up. Usually one gets hit by the kernel varibles being too low for stack size
and vm limits though to see that. BUT, I've actually got users who've hit
that wall too.

> As I've posted previously, I don't know where these specific formulas come
> from.  Some people have said that they come from disk salespeople.

Naw, more than likely from "That Poor Guy(tm)" who got to sit in an
univ. environment, rebuilding a machine time-after-time-after-time
until his TA's, or PH-d's programs would run. No one I've ever
spoken to really knows. In the late-70's, early 80's, before workstations,
many sites were just 1X RAM/SWAP.

> 
> >Why would you need more swap space then memory?   I believe I've
> >been told "so you can do a system dump".  What?  To floppy?  I
> >have 32M of memory.  I'm supposed to dump 96M to floppy?  Someone
> >pass me a clue please?  Thanks!

Machines can only hold so much RAM, so many processors, etc. Swapping
to disk is still infinitely better than *not being able to run your
programs*, albeit slower than RAM.


> 
> You need more swap space than memory if you want to run more programs than
> will fit in memory at once.  The machine I'm on right now has 64MB of RAM
> and is using 65MB of swap space.  However, this doesn't mean that it would
> not swap if we had 1MB more memory, because the text segments of programs
> don't use up swap space (at least on my system, a Sun), and memory is also
> used by the kernel for other things such as file buffers.

Heck, the machine I'm working on has 64MB of RAM, and 200 MB of swap.
That's not enough sometimes.....;>

> -- 
> Barry Margolin
> barmar@think.com          {uunet,harvard}!think!barmar

-- 
Steven C. Blair    DELL UNIX NETWORK OPERATIONS        sblair@dell.com
==========================================================================
"One form to rule them all, one form to find them, one form to bring them"
	"all and in the darkness rewrite the hell out of them."
                       -- Sendmail ruleset 3 comment from DEC
Xref: sparky comp.unix.internals:1076 comp.unix.sysv386:8293
From: dfields@hydra.urbana.mcd.mot.com (David Fields)
Newsgroups: comp.unix.internals,comp.unix.sysv386
Subject: Re: swap space
Date: 7 Apr 92 19:16:06 GMT
Reply-To: dfields@urbana.mcd.mot.com
Organization: Motorola, Inc.  Computer Group

In article <ktnuthINNd1e@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
>I'm also similarly confused about the RSS column.  For instance, if two
>processes are running the same executable, and one of them has some text
>pages swapped in, how can another one show up with 0 RSS?  There's clearly
>at least one page of its virtual memory resident (the page that is
>currently executing in the first process).

Off the top of my head I don't know what the SZ field is displaying
but the RSS (resident set size) field is the number pages that the
process currently has page table entries for.

If the pager stole a page that 2 processes had mapped and one of them,
process A, referneces it, then it will be counted in process A's RSS
but not in process B's.
--
Dave Fields	Motorola Computer Group		dfields@urbana.mcd.mot.com
SVR4: The Winchester Mystery Kernel		uiucuxc!udc!dfields
Newsgroups: comp.unix.internals
From: terry@ithaca.Eng.Sandy.Novell.COM (Terry Lambert)
Subject: Re: Accessing the PROCess table (how?)
Organization: Novell NPD -- Sandy, UT
Date: Fri, 17 Apr 1992 20:19:54 GMT

In article <12460@auspex-gw.auspex.com>, guy@Auspex.COM (Guy Harris) writes:
|> In article <1992Apr14.160552.12365@gateway.novell.com>, terry@ithaca.Eng.Sandy.Novell.COM (Terry Lambert) writes:
|> 
|> > 6)	Some information may not be available, since many things in the kernel
|> > 	can be swapped out, and a reference to /dev/kmem may not be sufficient
|> > 	to fault them in.  In particular, the user struct may be unavailable
|> > 	(this is not true of SunOS, which does not swap or relocate it's user
|> > 	structs).
|> 
|> Wrongo.  At least in 4.1[.x], it *does* page out U areas.
|> 
|> In article <1992Apr15.201258.9108@prl.dec.com> boyd@prl.dec.com (Boyd Roberts) writes:
|> 
|> >Only the currently running process' (ie. your proc table snooper) u-area
|> >will be mapped by /dev/kmem.
|> 
|> Wrongo.  In SunOS 4.1[.x], U areas aren't handled the "traditional" UNIX
|> way, in which they're always at a fixed virtual address, which is
|> remapped on a context switch.  They're all at *different* virtual
|> addresses in kernel space.
		This is what I meant by "relocate"
 
|> Actually, in SunOS 4.1[.x], touching that region of the kernel's virtual
|> address space *does* fault them in....

	...and this is what I meant by "doesn't swap", although my teminology was,
strictly, inaccurate.  I probably should have said "doesn't swap as part of user data",
rather than "doesn't swap", since what I meant was that it would be in kernel memory
when you needed it, unlike something that was truly process specific and therfore
accessable only through /dev/swap.

|> Given that the person didn't say what flavor of UNIX he was doing this
|> on, there are limits to how much information we can give him about
|> reading the U area, or even about reading the proc table....)

I *definitely* agree with this, which is why I didn't mention nlist(3), which I think we'll all
admit is sorta system specific.  There's no real reference to SunOS or even BSD, for
that matter.


						Terry Lambert
						terry_lambert@gateway.novell.com
						terry@icarus.weber.edu
Newsgroups: comp.unix.internals
From: bmrosen@screen.Princeton.EDU (Brian M. Rosen)
Subject: Accessing the PROCess table (how?)
Originator: news@ernie.Princeton.EDU
Organization: Princeton University
Date: Tue, 14 Apr 1992 01:03:55 GMT


	Could someone please tell me how to access the information stored in
the PROCess table.  I can't seem to find any reference to it in the MAN pages.
Thanks a lot.
							Brian
-- 
-------------------------------------------------------------------------------
|   Brian Rosen           |       "The human spirit is a hard thing to kill." |
|   Princeton University  |                "Even with a chainsaw."            |
|   No stress at all.     |                            -Tha Addams Family     |
From: Karl_Kleinpaste@cs.cmu.edu
Newsgroups: comp.unix.internals
Subject: Re: microkludgery (was Re: DEC-bashing)
Date: 6 Apr 92 13:23:46 GMT
Organization: Carnegie-Mellon Univ, Nectar Project

mjr@hussar.dco.dec.com writes:
   Does anyone really have any hard evidence that microkernels
   are worth jack?

There's a thread in comp.os.research, "Have we learned anything in the
last 20 years?," on which you may want to chime in.
From: dhesi@cirrus.com (Rahul Dhesi)
Newsgroups: comp.unix.internals
Subject: Re: How to know if file is on NFS filesystem?
Keywords: NFS
Date: 8 Apr 92 21:58:34 GMT
Organization: Cirrus Logic Inc.

In order of decreasing usefulness:

1.   Do a statfs system call and look at the f_files and f_ffree fields.
If either is -1, the file lies on a non-local filesystem such as NFS.

2.   To confirm this, create a scratch file in the same directory as the
file being tested, open that scratch file for reading and writing, and
then unlink it.  Now search for all filenames in the same directory that
look like .nfs* and unlink those too.  Now do lots of writes and reads to
the open file descriptor.  If they fail with strange errors like ESTALE
("stale NFS file handle") then it's a good bet that the original file was
indeed being accessed over NFS.

3.   Finally, you can do the barometer test.  Get a good barometer and
offer it to you sysadmin, saying "Mr. Sysadmin, I will offer you this
fine barometer if you will tell me whether my file is on an NFS-mounted
filesystem."
-- 
Rahul Dhesi <dhesi@cirrus.COM>
UUCP:  oliveb!cirrusl!dhesi
From: gertjan@west.nl (Gertjan van Oosten)
Newsgroups: comp.unix.internals
Subject: lseek(..., SEEK_END) behaviour
Keywords: lseek holey file
Date: 16 Apr 92 09:16:43 GMT
Organization: West Consulting bv, Delft, The Netherlands

The following behaviour occurs under SunOS (both 4.0 and 4.1):

If I seek beyond EOF [with lseek(..., SEEK_END)], and do it again, the
second lseek() does not seek from the last seek position, but from the last
written byte [example program below].
The manual says:

"                                  ...  If  whence  is  SEEK_END,
"    the seek pointer is set to the size of the file plus offset.

[The manual pages in 4BSD, X/Open and SVID make similar statements.  Note
 that SunOS, 4BSD and SVID mention holes, X/Open does not.]

What I want to know is:
  a. Do you consider this behaviour correct (w.r.t. the man-page)?
  b. Do you want this behaviour?

My personal opinion:
  ad a. This depends on the definition of 'the size (or length) of a file';
        I don't want to answer that one...
  ad b. I don't; I'd like to see lseek() move from the last position (but
        you already guessed that).


Consider the following example C program:

  #include <fcntl.h>
  #include <unistd.h>
   
  #ifndef SEEK_END
  #define SEEK_END        2
  #endif
   
  main()
  {
    int fd;
   
    fd = open("SoMeFiLeOrOtHeR", O_WRONLY|O_CREAT, 0660);
    printf("At %ld\n", lseek(fd, 65536L, SEEK_END));
    printf("At %ld\n", lseek(fd, 16384L, SEEK_END));
    close(fd);
    return 0;
  }


This gives the following output:

  At 65536
  At 16384

Regards,
--
-- Gertjan van Oosten, gertjan@west.nl
From: swist@doodly.mcc.dec.com (Jim Swist)
Newsgroups: comp.unix.wizards
Subject: Re: fork()  in OSF DCE
Keywords: threads
Date: 14 Apr 92 13:57:34 GMT
Reply-To: swist@took.enet.dec.com
Organization: Digital Equipment Corporation

We do this without any problem (although it's on Ultrix rather
than OSF but DCE is pretty much DCE.  Couple of things you
need to watch out for...

1) Make sure you mark any file descriptors (probably all of them
except 0,1,2) close-on-exec.  We used to have strange problems
when open sockets got passed to the  exec'd image.

2) If you do any manipulation of open FD's on the subprocess
side of the fork prior to exec(), make sure you #undef the 
DCEthreads wrappers.  You don't want pseudo-asynchonous
I/O started up again.

3) We fork a combination of processes whose terminations we
care about and those whose terminations we don't care about
(daemons etc).  To handle this in a thread-friendly (non-blocking)
manner, we run a single daemon thread off to the side which
essentially is a sigwait - wait3 loop.  If we catch a termination
we care about, we post a condition variable, otherwise we
just discard the exit status to prevent the horrors of zombie
buildup!
Xref: sparky comp.unix.wizards:2212 comp.unix.programmer:2397 comp.unix.internals:1119
From: hurtta@cs.Helsinki.FI (Kari E. Hurtta)
Newsgroups: comp.unix.wizards,comp.unix.programmer,comp.unix.internals
Subject: Re: Page Fault Handlers
Date: 15 Apr 92 17:38:43 GMT
Organization: Department of Computer Science, University of Helsinki, Finland

In article <kulvt9INN5l5@earth.cs.utexas.edu> wardrb@cs.utexas.edu (Richard Byron Ward) wrote:
> I posted these questions to comp.unix.questions yesterday, but I haven't 
> gotten any responses... Anyway, I have studied the problem more and have
> "discovered" sigaction, but which signals do I want to handle?  SIGBUS?
> SIGSEGV?  Also, do I have to alter exec in order to let other programs
> use my page handler?  

Page faults don't generate signals (in any UNIX or other OSes as far I know).
You can't create page fault handler without going to kernel.

- K E H
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.wizards
Subject: Re: Using SO_KEEPALIVE to detect the death of a client???
Date: 7 Apr 92 04:54:30 GMT
Organization: Massachusetts Institute of Technology

This question should hot have been posted in comp.unix.wizards.  I
have posted a response in comp.unix.programmer.

-- 
Jonathan Kamens						jik@MIT.Edu
MIT Information Systems/Athena		    Moderator, news.answers
    (Send correspondence related to the news.answers newsgroup
	{and ONLY correspondence related to the newsgroup}
		 to news-answers-request@MIT.Edu.)
Newsgroups: comp.unix.wizards
From: goldberg@turing.toronto.edu (Jody Goldberg)
Subject: Passing File Descriptors through Unix Domain Sockets
Keywords: descriptors sockets
Organization: CSRI, University of Toronto
Date: 17 Apr 92 16:13:15 GMT

Bsd & Sun manuals both mention that sendmsg/recvmsg can be used to pass
a file descriptor between 2 processes.  You stuff the descriptor in one
end of a unix domain socket, and at the other a new descriptor with the
same modes is opened refering to the  same file.  The drawback is that we
are never told HOW to perform this magic.  The include files don't give any
flags or show where to put the fd in the msg header.  The local consensus
is that it is not possible.

I have no intention of using this thing in a real program, but the mystery is
irking me.  Is it possible?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
goldberg@turing.toronto.edu		|	'I row ... what else matters?' 
Newsgroups: comp.unix.wizards