HDTenEightyP/NetNews huggingface dataset:
From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert)
Subject: Re: Disk decoding
Organization: Novell NPD -- Sandy, UT
Date: Tue, 8 Sep 1992 20:11:59 GMT

In article <1992Sep8.183206.248@menudo.uh.edu> cavers@menudo.uh.edu (Chris M. Cavers) writes:
>I would like to decode the information on a unix disk.
>I am using Sun OS 4.1.2.
>I am intercepting the block i/o calls at the device driver level.
>Given a byte offset and a number of bytes to move, I would like to be
>able to determine which file contains the data. 

If you are truly intercepting them, then the blocks should be in a cache
hung off the vnode (your interception is taking place before they are
removed from this cache).

You may either traverse the system open file table or the dnlc table to
identify the inode whose vnode contains a pointer to the block being written.
The inode will have to be looked up using an ncheck type process, which
you may do at the device driver level (in an extremely ugly fashion) by
traversing the directory tree.

I will probably be flamed for suggesting that this be done in the device
driver; however, using the normal interface will kill you by making those
blocks show up as well.

Alternately, you can assemble an in core inode/name resoloution list and
traverse it (assembling it prior to attempting logging of disk I/O).

In any case, there is no pretty way to do this.

					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.
Xref: sparky comp.unix.wizards:3830 comp.sys.sun.misc:4114
From: drk@twinkie.Rational.COM (David Kaelbling)
Newsgroups: comp.unix.wizards,comp.sys.sun.misc
Subject: Reducing "reserved" swap space?
Keywords: SunOS, shared libraries, swap
Date: 7 Sep 92 17:44:23 GMT
Followup-To: poster


Can anybody explain what exactly determines the "reserved" swap space
allocated by a program, and how I can reduce this number?

I have a large application (running on Sun-4's under SunOS 4.1.x), and
want to have several copies of the application running concurrently.
Currently the swap space requirements are a major obstacle.  According
to "pstat -s" each copy of the application allocates 1.5Mb of swap and
reserves 9.4Mb.  Purify reports that the heap is around 3.5 Mb.  To
the untrained eye it appears that swap space is reserved for the
entire text segment (size reports 6430kb text, 876kb data, 29kb bss),
but never used.  How can I eliminate or amortize this waste?

I put most of the code into shared libraries; they help but add 20
seconds to the startup time of the application, which is unacceptable.

I tried "ld -n"; that just moved 6.5Mb from reserved to allocated.

I tried setting the sticky bit (as root, since doing it normally fails
silently); swap space requirements were unchanged.

I've searched through many TFM's to no avail.  The bulk of the code is
compiled with -PIC already (a relic of shared libraries).
--
David Kaelbling                            (508) 520-8632 [home -7826]
12 Mountain Rock Ln.; Norfolk, MA 02056-1772   DKaelbling@Rational.COM
From: ericb@rigel.cs.pdx.edu (Furry Logic)
Newsgroups: comp.unix.wizards
Subject: STREAMS info
Summary: How the $%@! do you push a module?
Date: 9 Sep 92 09:28:26 GMT
Article-I.D.: pdxgate.6081


  I know this subject was just discussed, but out site expires messages
on the second. I'm trying to re-create the null module in the STREAMS
Programming Book, but there does not appear to be so much as a paragraph
giving details for pushing a stream (just some weird ioctl() call passing
a string, of which I cannot see how that forwards the streamtab struct).
Any information (or better yet, location of sample STREAMS modules) would
be most appreciated (and I'm supposed to give a discussion over this puppy).
  Thanx!

-e.b.

  Eric Berggren             |  "Sometimes I think the surest sign that
  Computer Science/Eng.     |   intelligent life exists elsewhere in the
  Computer Action Team      |   Universe is that none of it has tried to
  ericb@rigel.cs.pdx.edu    |   contact us."        -- Bill Watterson
From: ram@eiffel.com (Raphael Manfredi)
Newsgroups: comp.unix.wizards
Subject: Getting the Ethernet address from a network interface
Keywords: network, ethernet, IP, arp
Date: 6 Sep 92 20:22:42 GMT
Organization: Interactive Software Engineering, Santa Barbara CA

Hi!

I am facing what appears to be a simple problem, but cannot seem to
be able to solve it. What I want is to retrieve the ethernet address
of the machine. Unfortunately, this has to be done from a program with
no super-user privileges.

I know the ARP protocol, but the informations are kept in the kernel
data space, and the mapping between IP and Ethernet addresses is done
only for the other machines, not the local host. And I did not manage
to find a system call which would probe the ethernet device and give
me its ethernet address.

There is obviously a shell solution which works sometimes:

	remsh another_host /etc/arp my_host | sed -e 's/^.*at //'

but this is not really acceptable. And the other host might not have
the maping in its kernel. An arbitrary program cannot depend on this
to get the local Ethernet address...

What I managed to do so far is getting a datagram socket and calling
an iotcl SIOCGIFCONF on the socket descriptor, which gives a list of
the network interfaces available. In particular the struct ifreq
contains the sockaddr information, providing me with the IP address
(ifr_addr field from struct ifreq, which is a struct sockaddr).

But how do you get to the struct ether_addr? Is there a way at the
user level (i.e. with no root privilege) to force an arp resolution
and then retrieve that information from the kernel via a system call?
On my machine, /usr/etc/arp is setgid to sys, indicating the program
is reading /dev/kmem directly, i.e. the information retrieval is not
easily portable from kernel to kernel.


Thank you for any information on this topic.
-- 
Raphael Manfredi <ram@eiffel.com>
Interactive Software Engineering Inc.
270 Storke Road, Suite #7                      / Tel +1 (805) 685-1006 \
Goleta, California 93117, USA                  \ Fax +1 (805) 685-6869 /
Newsgroups: comp.unix.wizards,comp.unix.questions
From: miquels@htsa.aha.nl (Miquel van Smoorenburg)
Subject: Re: reliable signals under BSD / SVR4
Keywords: signals, reliable, software interrupts
Organization: Algemene Hogeschool Amsterdam, The Netherlands
Date: Sun, 6 Sep 1992 09:16:51 GMT

In article <1992Sep3.231707.17858@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>>Has anyone investigated other models for signal delivery?
>
>In the SVR4 sigaction(2) man page under SA_SIGINFO it says that the
>signals are "reliably queued."  Apparently SVR4 can provide queued
>signals, but someone-in-the-know told me that Sun made AT&T take this
>feature out (when they were working on SVR4 together).  Perhaps POSIX.4
>will have them put it back in ...
>
>>Come to think of it, doesn't it make it somewhat "tricky" to use
>> async. I/O at all?
>
>I've yet to find a real application that actually uses BSD's SIGIO.
>Has anyone seen one?
>
>	Rich Stevens  (rstevens@noao.edu)

Some time ago I ported the trs80 emulator for X (xtrs) to Linux. It wasn't
very difficult, except that it used SIGIO to catch keyboard events.
And Linux (or all other non-BSD systems, for that matter) doesn't have
SIGIO. So at the initialization, the process fork()s and then the child
process does a select() on the fd #0. When it receives data, it sends a
SIGIO (#define SIGIO SIGUSR1) to it's parent, and hits itself
with SIGSTOP. Then, when the parent is done reading the data in the signal
handler, it sends it's child the SIGCONT signal and it's ready to roll
again. Neat eh?

Mike.
--
%     Miquel van Smoorenburg, Baljuwstraat 20, 2461SL Langeraar, Holland.     %
%   miquels@htsa.aha.nl (school)       miquels@drinkel.nl.mugnet.org (home)   %
%                   Calm down - it's just ones and zeros                      %
-- 
%     Miquel van Smoorenburg, Baljuwstraat 20, 2461SL Langeraar, Holland.     %
%   miquels@htsa.aha.nl (school)       miquels@drinkel.nl.mugnet.org (home)   %
%                   Calm down - it's just ones and zeros                      %
Newsgroups: comp.unix.wizards
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: /bin/rm security issue(s)
Organization: Weber State University  (Ogden, UT)
Date: Fri, 11 Sep 92 01:59:34 GMT

In article <1992Sep10.015705.7210@morwyn.uucp> forrie@morwyn.uucp (Forrie Aldrich) writes:
>I am aware that when a file is deleted, the blocks are made 'free' for
>writing, but the files contents can still linger about on the disk; and
>as such can be effectively retrieved with a good program.  I've a couple
>of programs (which have saved my life :) that do this.
>
>However:  I'm concerned about being able really _eradicate_ a file,
>for various reasons including security.
>
>Does anyone have a program that will do this?  A friend suggested that 
>I get a program that will open the file and write 'zeros' or something
>to the end of it and then close it. _Then_ /bin/rm the file.
>
>I could see adding this 'feature' to /bin/rm or perhaps writing a
>program called /bin/rrm (_really-remove_) to do this.  Hmmm... I wonder
>how government contracts manage this issue...

The government does it by writing an ANSI standard pattern an ANSI standard
number of times using an ANSI standard order to coerce seeks from different
directions so as to destroy any data that exists in the file plus any info
which can be derived after it's simply written over which may "smear out"
due to hysterisis in the disk head.

Since UNIX like to optimize seeks, this requires a special device driver
(no, not ANSI standard, to my knowledge ;-)) to do the dirty deed, and
special code in the file system for removal.

I know VMS supports this directly (no file system cache to worry about),
and I believe that the Norton Futilities for MS-DOG can do the same if
given the correct options.


					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Newsgroups: comp.unix.wizards,comp.unix.programmer,comp.unix.internals
From: rstevens@noao.edu (W. Richard Stevens)
Subject: Re: Implementation of Sys V. based message queues
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Date: Tue, 8 Sep 1992 20:24:05 GMT

>> [ complaints of mine about AIX's select that also selects on
>>   messages queues ... ]
>
>Why? Is the implementation so awful?  I remember I almost barfed too but 
>just because it was a new, strange select() that wasn't what I was used
>to see.
>
>Anyway, I'm not trying to say that it's a great implementation, that
>I don't know now, I just want to hear why it's bad.
>
>At least they did something ...

OK, here are my complaints.  First a disclaimer: I've never used AIX,
I've just seen the man page for their select for the RS/6000.

They use the same name (select) for a function that's been used for
10+ years with different arguments.  Never use the same name for a
different function, even if it does similar things.  They should have
defined a new function (selectq ?) with new arguments to handle message
queues.  They should have also kept the first 5 arguments to this new
function identical to the existing select.

Next, they changed the first argument so that the high-order 16-bits
are for one thing and the low-order for something else.  Yuck.  If you
have to specify two counts (# of descriptors and # of message queues)
then use 2 arguments!

Next, the middle three arguments aren't pointers to fd_set variables,
they're pointers to an array of struct sellist.

My bottom line is that it appears that I would have to take every
program using select that doesn't give a hoot about System V message
queues and recode the selects to conform to this new interface.  Yuck.
(Maybe they have some #defined constant that brings in the BSD-style
select--I just don't know.)

	Rich Stevens  (rstevens@nooa.edu)
From: ascent!paul@uunet.uu.net (Paul Foley)
Newsgroups: comp.unix.wizards
Subject: please unsubscribe
Date: 15 Sep 92 17:18:51 GMT


please unsubscribe
Newsgroups: comp.unix.wizards
From: pnarayan@cs.tamu.edu (P S Narayan)
Subject: Filemanager
Organization: Computer Science Department, Texas A&M University
Distribution: usa
Date: Tue, 8 Sep 1992 21:23:11 GMT

Hello,
The disk driver will hide the details of disk addresses from the higher
level layers. The file manager is one such higher layer. Does this mean
that the disk block allocate and deallocate routines of the file manager
return logical offsets of block addresses, which the driver uses later on
for reading or writing.
What I am asking is, are the values of direct and indirect pointers in
the inode for a file logical offsets ?

Thanks
Narayan
pnarayan@cs.tamu.edu

Newsgroups: comp.unix.wizards,comp.unix.programmer,comp.unix.internals
From: lpc@dickens.com (Luis P Caamano)
Subject: Re: Implementation of Sys V. based message queues
Date: Tue, 8 Sep 1992 17:10:14 GMT
Organization: Dickens Data Systems, Inc.

In article <1992Sep3.232807.18181@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:
>>> I would like to be able to use select(2) to multiplex descriptor based
>>> objects (sockets) as well as the message queue.
>>
>> I could be mistaken, but my experience with using Sys V IPC with select()
>> is:  'aint no way...
>
>Believe it or not, I just found out that AIX on the RS/6000 actually
>provides a function named select() with a different interface that
>actually lets you multiplex both descriptors and message queues.
>When I saw their interface I almost barfed.

Why? Is the implementation so awful?  I remember I almost barfed too but 
just because it was a new, strange select() that wasn't what I was used
to see.

Anyway, I'm not trying to say that it's a great implementation, that
I don't know now, I just want to hear why it's bad.

At least they did something ...
-- 
---------------------------------------------------------------------------
Luis P. Caamano                    |         lpc@dickens.com
Dickens Data Systems, Inc.         |         uunet!dickens.com!lpc
Atlanta, GA                        |         (404) 475-8860
---------------------------------------------------------------------------
If I think I know it all, I'll stop learning. -myself
The more I learn, the more I know I know nothing. -somebody else
From: davidh@camelot.bradley.edu (David Henderson)
Newsgroups: comp.unix.wizards
Subject: drop me from all lists, please!
Date: 11 Sep 92 17:14:24 GMT

Please drop me from all of your mailing lists at brl.mil
This is the third request and that is why I am now sending 
this message to everyone who might be able to get this done.
Newsgroups: comp.unix.wizards
From: pham@ucselx.sdsu.edu (Peter Pham)
Subject: How md_space in struct mb_device defined?
Keywords: [SunOS4.1.1]
Organization: San Diego State University Computing Services
Date: Wed, 9 Sep 1992 23:19:10 GMT


I am trying to make a device driver loadable on SunOS 4.1.1
(on a Sun4/330).  There is a structure 'mb_device' that I need
to initialize.  Under this structure, there is a field called
'u_int  md_space'.  The comment for this field (structure 
defined in <sundev/mbvar.h>) says this is a field for "encoded
address space".  Suppose I want the VME address space of 32D32,
what should I put in this field?  Does anyone know the "encoded
address space" is pre-defined some where?

Thanks in advance.

Peter Pham
Xref: sparky comp.unix.wizards:3864 comp.unix.programmer:4592 comp.unix.internals:1784
From: rstevens@noao.edu (W. Richard Stevens)
Newsgroups: comp.unix.wizards,comp.unix.programmer,comp.unix.internals
Subject: Re: Implementation of Sys V. based message queues
Date: 9 Sep 92 19:50:36 GMT
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA

>Does anybody use message queues anyway? For something that can't be done
>just as easily with named pipes or Unix-domain sockets?

The only things you get with System V message queues are record
boundaries (which you get with datagram Unix domain sockets,
but then you have to provide your own flow control) and the ability
to assign a type (e.g., priority) to each message, and use this
priority to choose which record to read next.

But, as others have already pointed out, there are *so many* drawbacks
to using them that new applications should avoid them like the plague.
Lots of people used to claim a need for them since they used to be
fast, but today they are no faster than Unix domain stream sockets
or SVR4 stream pipes.

	Rich Stevens  (rstevens@noao.edu)
From: ZA9ZA00@sysa.computing-services.manchester-poly.ac.uk
Newsgroups: comp.unix.wizards
Subject: SUN/HYUNDAI compatibility
Date: 3 Sep 92 09:06:51 GMT

Hi,
  My boss has just dumped a HYUNDAI sparc on my desk and asked if it is
'the same' as a SUN IPC. It runs SUNOS 4.1.1 ok and all the tests I've
run on it have gone ok. Does anyone know of any incompatibilities, problems etc?

                                Cheers,
                                John.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
J.E.Brooks, Team Leader (systems/networks), Computing Services Unit,
            Manchester Polytechnic, Chester Street, Manchester M1 5GD
       Tel: (+44) 61 247 1463
      Mail: J.Brooks @ uk.ac.manp.cs.sa
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Newsgroups: comp.unix.wizards,comp.unix.programmer,comp.unix.internals
From: lpc@dickens.com (Luis P Caamano)
Subject: Re: Implementation of Sys V. based message queues
Date: Wed, 9 Sep 1992 15:12:16 GMT
Organization: Dickens Data Systems, Inc.

In article <1992Sep8.202405.24405@noao.edu> rstevens@noao.edu (W. Richard Stevens) writes:

[ some stuff deleted ]

>
>My bottom line is that it appears that I would have to take every
>program using select that doesn't give a hoot about System V message
>queues and recode the selects to conform to this new interface.  Yuck.
>(Maybe they have some #defined constant that brings in the BSD-style
                       ^^^^^^^^

In fact, you don't notice the change in select until you read the
man page, and then you jump off your seat :-) 

No. You don't have to change the code and yes, /usr/include/sys/select.h
contains some #define's to simplify the use of low/high bits separation but
no special kludges to make it look BSD.  (fd_set it's still there).

----excerpt from /usr/include/sys/select.h (AIX 3.2)-----
#include <sys/time.h>

extern	int select(
	unsigned long nfdsmsgs,	/* #file descriptors/message queues */
	void *readlist,		/* file descriptors to check for read */
	void *writelist,	/* file descriptors to check for write */
	void *exceptlist,	/* file descriptors to check for exceptions */
	struct timeval *timeout);	/* length of time to wait for events */

...

typedef unsigned int	fd_mask;
#define NFDBITS	(sizeof(fd_mask) * NBBY)	/* bits per mask */
#ifndef howmany
#define	howmany(x, y)	(((x)+((y)-1))/(y))
#endif

typedef	struct fd_set {
	fd_mask	fds_bits[howmany(FD_SETSIZE, NFDBITS)];
} fd_set;

#define	FD_SET(n, p)	((p)->fds_bits[(n)/NFDBITS] |= (1 << ((n) % NFDBITS)))
#define	FD_CLR(n, p)	((p)->fds_bits[(n)/NFDBITS] &= ~(1 << ((n) % NFDBITS)))
#define	FD_ISSET(n, p)	((p)->fds_bits[(n)/NFDBITS] & (1 << ((n) % NFDBITS)))
#define FD_ZERO(p)	bzero((char *)(p), sizeof(*(p)))
----------------------------------------

-- 
---------------------------------------------------------------------------
Luis P. Caamano                    |         lpc@dickens.com
Dickens Data Systems, Inc.         |         uunet!dickens.com!lpc
Atlanta, GA                        |         (404) 475-8860
---------------------------------------------------------------------------
If I think I know it all, I'll stop learning. -myself
The more I learn, the more I know I know nothing. -somebody else
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.wizards
Subject: Re: /bin/rm security issue(s)
Date: 10 Sep 1992 05:25:43 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <1992Sep10.015705.7210@morwyn.uucp> forrie@morwyn.uucp (Forrie Aldrich) writes:
>However:  I'm concerned about being able really _eradicate_ a file,
>for various reasons including security.
>
>Does anyone have a program that will do this?  A friend suggested that 
>I get a program that will open the file and write 'zeros' or something
>to the end of it and then close it. _Then_ /bin/rm the file.

I don't know whether Unix guarantees that writing to a file will overwrite
the existing blocks rather than allocate new blocks and free the old ones.
However, I believe most existing Unix implementations will do what you
expect.

>I could see adding this 'feature' to /bin/rm or perhaps writing a
>program called /bin/rrm (_really-remove_) to do this.  Hmmm... I wonder
>how government contracts manage this issue...

This won't help in the case of files deleted in other ways, e.g. by mv(1),
or by applications that call unlink(2).  Perhaps you should replace
unlink(2) in libc with one that really eradicates (if you have dynamic
libraries, this change will affect all dynamically-linked programs).

I don't think this is a problem for government contracts.  The Orange Book
only requires that newly-created files not contain data from old files,
which Unix implements.  Anyone who can access the raw disk is effectively
bypassing the system security.  On Unix, if you can do this it generally
means that you also have access to replace or patch /bin/rrm so that it
doesn't really eradicate, either.  In general, I think that a contract that
required this kind of security would probably not be met by Unix.  On the
other hand, Multics deletes files similarly to Unix, and that wasn't an
obstacle to getting a B2 rating.

The only government requirement for really eradicating data comes into play
when disks or tapes are being thrown out.  If the media ever contained data
above a particular security classification, it has to be thoroughly wiped;
this generally involves writing lots of 1's, 0's, and random patterns over
it several times, then degaussing it.  At some really high levels, you have
to grind it up into a fine powder, and then incinerate it; but first you
have to erase it as described above!
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.unix.wizards
Subject: Re: A few UNIX questions
Date: 8 Sep 1992 12:06:24 +0200
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: 127.0.0.1

In comp.unix.wizards, article <32176@adm.brl.mil>,
  mike@BRL.MIL ( Mike Muuss) writes:
> 
> From: Michael Panosh <mwp.michael@melpn1.prime.com> PrimeService, Australia
> 
> > Can *anyone* tell me why the file size is a signed integer.  Surely there
> > is no need for negative sized files!!
> 
> Because lseek() needs to be able to return -1 on error, and not have it
> look like a valid file offset.

Strictly speaking, that's an artifact of the way lseek() is implemented.

On many if not all  UNIXes, system calls are executed somewhat along these
lines:
- Get arguments from stack and put them into registers, if necessary
- put the system call number in another register
- _Trap
- If a certain CPU condition code bit is [set/clear], then (Error)
  - Move the return value (in a register) to errno
  - set that register to -1
- return

I don't really like that way of using system calls, but it's kind of too
late to change it at this time.  :-/

-- 
Wherever you go...There you are.
- Buckaroo Banzai
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/
Newsgroups: comp.unix.wizards,comp.unix.questions