lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
eec934fe6cdf00ff46c70c324c1949d18222ecc3
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest308
gohigh 32616db5a4 add directory ftp-archives
2024-02-19 00:24:15 -05:00

625 lines
24 KiB
Plaintext
Raw Blame History

From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
To: Linux-Development@senator-bedfellow.mit.edu
Reply-To: Linux-Development@senator-bedfellow.mit.edu
Date: Fri, 14 Oct 94 17:13:09 EDT
Subject: Linux-Development Digest #308
Linux-Development Digest #308, Volume #2 Fri, 14 Oct 94 17:13:09 EDT
Contents:
Re: Shared Libs: working toward a permanent solution? ("Theodore Ts'o")
Re: Filesystem idea (H. Peter Anvin)
Re: Linux killed my floppy drive! (Ahmed Naas)
Re: Linux NOT logging people out on hangup (Matthias Urlichs)
Re: PGP for Linux?? (Brian J. Swetland)
Re: 1.1.53 - fdformat - IOCTL error still there (Rene COUGNENC)
8-bit colour ANSI and ncurses (Rasmus Lerdorf)
2nd RFD: comp.os.linux reorganization (Dave Sill)
90+% cpu for HD access, too high? (Shaune Beattie)
compiling modules for 1.1.52 (Benjamin John Walter)
Re: Physical Memory size (Lee Crawford)
Re: Looking for X graphics/ Plotting libraries (Wade Scholine)
* Please help with RPC Error * (Rajib Rashid)
Re: A badly missed feature in gcc (H. Peter Anvin)
Re: Physical Memory size (H. Peter Anvin)
----------------------------------------------------------------------------
From: "Theodore Ts'o" <tytso@MIT.EDU>
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 14 Oct 1994 13:22:55 -0400
Reply-To: tytso@MIT.EDU
Date: Fri, 14 Oct 94 09:12:10 MDT
From: Bryan Ford <baford@schirf.cs.utah.edu>
>The real problem with this sort of solution is that you have to educate
>GCC about segment registers, and you have to include the segment number
>into a pointer. Otherwise, how is GCC supposed to know whether a
>pointer was pointing at memory from the library's data segment, or at
>memory passed in from the caller?
It doesn't need to. Any pointer that actually gets passed around in
a program in variables and such is still a 32-bit, absolute, "small model"
pointer as usual. The only thing that needs to be changed is the method
of accessing or taking the address of a static variable. To take the
address of a static variable, just convert the segment-register-relative
offset to a global, absolute offset by adding the base address of the
library, and use the resulting absolute pointer thereafter. This will
work as long as a particular shared library doesn't move around in
a particular process's address space _while_it_is_running_, which would
be rather insane anyway. :-)
Unfortuantely, life's not that simple. What if you take the address of
a static variable, and store it into a structure? That structure member
might contain a pointer to a static variable local to the shared
library, or it might contain a pointer to memory in the main program's
data segment.
Or what the library routine needs to return the pointer to a static
variable, like gethostbyname() does?
Or what if the library program wants to call strlen(), strcpy(), or
strcat()? Those routines won't know if the passed in pointer is in the
program's data segment, or in the shared library's data segment.
If you ignore this problem, then you either (a) prohibit the shared
library from calling other shared library routines when those routines
take pointers as arguments, or (b) you play games like we have to in the
kernel, where you have to temporarily save the ds segment register,
modify to point to the library's data segment, and then call strlen().
But as unpleasant as option (b) is, that still doesn't work in the
general case. Consider a situation where shared library (a) Motif,
calls shared library (b) XFree86, which calls shared library (c) libc.
Now suppose that Motif passes a string from its data segment to Xfree86,
and Xfree86 wants to call strcmp on a string in Motif's data segment,
and with one in its data segement. Thus, strlen would be asked to
compare strings in two different segements ---- hence, it must be
segment aware, and this requires compiler support.
Without compiler support, people who code shared libraries would have
to be very aware of the segmentation issues, since they would have to
handle them by hand --- just as we do in the kernel. I doubt that would
be popular with applications programers.
- Ted
------------------------------
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: Filesystem idea
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Fri, 14 Oct 1994 13:40:00 GMT
Followup to: <wpp.782136465@marie>
By author: wpp@marie.physik.tu-berlin.de (Kai Petzke)
In newsgroup: comp.os.linux.development
>
> >I heard of a story about a system (for non-programmers) deletes all
> >core files every night. Then a scientist wrote a paper and named the
> >file "core"...
>
> There is also the story of a poor guy named John Core, user name "core",
> whose mail (from /var/spool/core) got deleted regularly.
>
A proper truncation script really should use "file" or some other
appropriate tool to double-check that an *.o file is an *.o file, a
core is a core, etc. It is pretty easy to do, although it is not as
easy as a simple find command in the root cronfile.
--
INTERNET: hpa@nwu.edu --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL HAM RADIO: N9ITP or SM4TKN
FIDONET: 1:115/511 or 1:115/512 STORMNET: 181:294/1 or 181:294/101
Fatal error: Turing machine detected end of tape
------------------------------
Crossposted-To: comp.os.linux.help
From: ahmed@oea.xs4all.nl (Ahmed Naas)
Subject: Re: Linux killed my floppy drive!
Date: Thu, 13 Oct 1994 19:57:14 GMT
Rob Janssen (rob@pe1chl.ampr.org) wrote:
: The answer probably is: Yes, Linux killed your floppy drive.
: When you would have used another (much more popular) operating system
: for the PC, the system would have been rebooted several times a day, the
: floppy would have seeked each time it went to the BIOS selftest, and dirt
: would not have accumulated on the mechanism.
: Don't run stable operating systems! They may kill your drive!
Rob,
I hate to disappoint you but I also run DOS/WIN and NT on the same
machine. Flame away :-)
--
The above is a result of random neuron activity in the writer's brain.
Ahmed M. Naas ahmed@oea.xs4all.nl
======================================================================
------------------------------
From: urlichs@smurf.noris.de (Matthias Urlichs)
Crossposted-To: comp.os.linux.admin
Subject: Re: Linux NOT logging people out on hangup
Date: 14 Oct 1994 14:17:34 +0100
In comp.os.linux.development, article <bart.155.00160B65@dunedin.es.co.nz>,
bart@dunedin.es.co.nz (Bart Kindt) writes:
>
> I am running a multi-line SLIP dialin server. For months we have had problems
> that sometimes the "sliplogin" program was not getting killed. We finally
> found that the problem is in the Kernel " close() " function; this function
> does sometimes *not return*. We have fixed the problem with a patch that
> re-kills the program after a 15 second timeout, when it is still 'alive'.
Ahem... if close() really doesn't return, a kill won't make any difference.
Anyway, a cursory look at 1.1.53 doesn't reveal any loops the close could
hang in.
Which kernel/sliplogin version are you using?
--
Matthias Urlichs \ XLink-POP N<>rnberg | EMail: urlichs@smurf.noris.de
Schleiermacherstra<EFBFBD>e 12 \ Unix+Linux+Mac | Phone: ...please use email.
90491 N<>rnberg (Germany) \ Consulting+Networking+Programming+etc'ing 42
PGP: 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE
Click <A HREF="http://smurf.noris.de/~urlichs/finger">here</A>.
------------------------------
From: brian@floyd.urh.uiuc.edu (Brian J. Swetland)
Subject: Re: PGP for Linux??
Date: 10 Oct 1994 19:53:56 GMT
Zack T. Smith (zack@netcom.com) wrote:
: Hi,
: Can anyone tell me whether PGP (the encyption utility) been ported Linux?
: I haven't been able to find it in the archives...
: Thanks,
: Zack Smith
It compiles 'out of the box' under Linux... you basically un-tar it and do a
'make linux'. Very simple. Works incredibly well.
PGP is available at ftp.netcom.com in /pub/mpj, I believe...
Their is also a site at MIT, but I'm not entirely sure on that.
=====
Brian J. Swetland | Linux 1.1.49 | AutoSignatureQuote v3.7 initializing ...
swetland@uiuc.edu | XFree86 2.1.1 | Segmentation Fault
------------------------------
From: rene@renux.frmug.fr.net (Rene COUGNENC)
Subject: Re: 1.1.53 - fdformat - IOCTL error still there
Date: 13 Oct 1994 04:09:31 GMT
Reply-To: cougnenc@blaise.ibp.fr (Rene COUGNENC)
Ce brave Ove Ewerlid ecrit:
> > For me 1.1.53 does not boot at all.
> > The kernel hangs after the CSLIP message, probably when detecting
> > the ethernet card (ne 2000).
>
> We have similar problems with machines equiped with NE2000 cards.
> They boot OK after a hardreset or powerdown but not after a softreset.
No cure for me, same results after a hard or soft reset...
This NE2000 card has been detected proprely with all previous
kernel versions...
I have been told that there is a conflict with the 3c503 driver,
and I use it since my other Linux box uses this card.
Anyway, this 1.1.53 is running on this second machine, a public
access Linux. And a few hours ago I got a kernel panic on someone
logging with SLIP. The syslog file unfortunately contains no
trace of this problem and I could not note it manually, I
remember it was a "kfree on non allocated memory", something
like that.
1.1.52 ran 17 days, with T'Tso tty and serial patches and the
Alpha ppp driver, with no problem... 1.1.53 hangs on detecting
ne2000 and panics... May be too many things have changed :-)
--
linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux
------------------------------
From: rasmus@io.org (Rasmus Lerdorf)
Subject: 8-bit colour ANSI and ncurses
Date: 12 Oct 1994 07:46:20 -0400
I am having some problems getting ncurses to display
semi-graphical characters on the Linux console. I would like
to be able to use the same character set used by PC's running
ANSI.SYS for example. ie. ASCII character 178 is a checkered
block. When I output ASCII code 178 from my ncurses program
I do not get this checkered block. Is it enough to simply kick
the console driver into its "acs" mode? (Alternate Character Set)
And if so, how do I do that from within my program? Perhaps I
need to use some raw 8-bit ncurses output mode? I have been
unable to find anything related to this in the ncurses documentation.
Perhaps I can permanently replace my console character set with
a PC-like set?
Any suggestions would be greatly appreciated.
--
Rasmus Lerdorf .. rasmus@io.org
------------------------------
From: Dave Sill <de5@sws5.ctd.ornl.gov>
Crossposted-To: news.announce.newgroups,news.groups,comp.os.linux.help,comp.os.linux.announce,comp.os.linux.misc,comp.os.linux.admin
Subject: 2nd RFD: comp.os.linux reorganization
Date: 14 Oct 1994 15:45:43 -0400
REQUEST FOR DISCUSSION (RFD)
comp.os.linux reorganization
Summary: An extensive reorganization of the comp.os.linux hierarchy is
proposed. It includes the creation of five unmoderated
groups, the renaming of three unmoderated groups, and the
creation of one moderated group.
Proponent: Dave Sill, de5@ornl.gov
History: This proposed reorganization was prompted originally by the
excessive level of traffic in comp.os.linux.help. Following
a straw poll conducted by the proponent, an RFD was posted
for breaking comp.os.linux.help into various subgroups and
creating comp.os.linux.answers for separating the
documentation and announcements currently posted to
comp.os.linux.announce. During the discussion period, it
became evident that it would be preferable to create the
groups directly under comp.os.linux, rather than splitting
comp.os.linux.help. The previous RFD reflected that change.
This revision of the RFD incorporates several other changes
resulting from the previous 11 days of discussion.
1) Create group: comp.os.linux.advocacy (unmoderated)
Charter: For discussion of the benefits of Linux compared to other
operating systems.
2) Create group: comp.os.linux.answers (moderated)
Charter: For posting Linux FAQs, How-To's, READMEs and other
documents that answer questions about Linux. This will
help keep the traffic down in other c.o.l.* groups and will
leave comp.os.linux.announce for true announcements.
C.o.l.answers will be moderated by Matt Welsh
(mdw@cs.cornell.edu), the moderator of c.o.l.announce.
3) Create group: comp.os.linux.development.apps (unmoderated)
Charter: For questions and discussion regarding the writing of
applications for Linux and the porting of applications to
Linux.
4) Create group: comp.os.linux.hardware (unmoderated)
Charter: For questions and discussion specific to a particular piece
of hardware, e.g., "can this system run Linux?", "how do I
use this disk drive with Linux?", etc.
5) Create group: comp.os.linux.networking (unmoderated)
Charter: For questions and discussion relating to networking or
communications including Ethernet boards, serial
communications, SLIP, etc.
6) Create group: comp.os.linux.x (unmoderated)
Charter: For questions and discussion relating to X Window System,
version 11, compatible software including servers, clients,
libraries, and fonts, running under Linux. XFree86 issues
not unique to Linux will be directed to
comp.windows.x.i386unix.
7) Rename group: comp.os.linux.development (unmoderated)
to: comp.os.linux.development.system (unmoderated)
Charter: For questions and discussion regarding the development of
the Linux operating system proper: kernel, device drivers,
loadable modules.
8) Rename group: comp.os.linux.admin (unmoderated)
to: comp.os.linux.setup (unmoderated)
Charter: For questions and discussion relating to Linux installation
and system administration.
Rationale: "setup" is clearer than "admin", and is a more obvious
place for installation questions.
9) Rename group: comp.os.linux.help (unmoderated)
to: comp.os.linux.misc (unmoderated)
Rationale: Comp.os.linux.help is too general. It currently overlaps
comp.os.linux.admin, and if the proposed groups are
created, will overlap comp.os.linux.hardware and
comp.os.linux.networking as well as comp.os.linux.setup.
Note: The intent here is actually to remove comp.os.linux.help,
not to rename it to .misc, which already exists.
Unfortunately, it's not possible to remove it directly.
Comp.os.linux Reorganization Roadmap
Current Hierarchy Proposed Hierarchy
c.o.l.advocacy
c.o.l.announce c.o.l.announce
c.o.l.answers
c.o.l.development c.o.l.development.system
c.o.l.development.apps
c.o.l.help
c.o.l.hardware
c.o.l.misc c.o.l.misc
c.o.l.networking
c.o.l.admin c.o.l.setup
c.o.l.x
After a discussion period of 21-30 days, if there are not overwhelming
objections to any of the proposed groups, there will be a Call For
Votes (CFV) posted to the groups as this RFD. The voting period will
be at least 21 days. Each proposal that passes, by receiving 100 more
YES votes than NO votes and twice as many YES votes as NO votes,
will be implemented.
------------------------------
From: sdgb1@cus.cam.ac.uk (Shaune Beattie)
Subject: 90+% cpu for HD access, too high?
Date: 13 Oct 1994 22:01:08 GMT
I recently started to use hdparm to set the multiple sector count for my
drive (a conner 540Meg EIDE drive with a max mlt of 128). With it set to
0-32 no difference is noticed and I have a transfer rate (got via hdparm
-t) of around 3meg/sec *BUT* with a cpu usage of around 95%
with it set to 64 or 128 cpu usage drops to 40% but the transfer rate
drops to about 1meg/sec.
Is the 90% cpu usage something to worry about? (the system is a p-90 512k
cache, micronics pci mb, 16meg ram).
thanks
-----------------------------------------------------------------------------
|Snail: |Email: (choose one of) |Tel: +44(0)223 501878 |
|Shaune Beattie |sdgb1@cam.ac.uk |(From 13/10/94) |
|St. Catharine's College |shaune@beattie.demon.co.uk |Thought for the day... |
|Cambridge CB2 1RL | |I need a better sig :) |
-----------------------------------------------------------------------------
------------------------------
From: ben@tsunami.demon.co.uk (Benjamin John Walter)
Subject: compiling modules for 1.1.52
Date: Thu, 13 Oct 1994 08:47:25 +0000
Hi,
I tried to compile the example drv_hello module for my 1.1.52
kernel. After a little tweeking (doesn't everyone keep their source
in /usr/src/linux rather than /linux?), I got it to compile. However,
when I tried to insmod it, it complained that _kernel_version was
undefined. In the end I got it to work by changing:
static char kernel_version[] = UTS_RELEASE;
to
char kernel_version[] = UTS_RELEASE;
Now it loads and runs fine ;-) Was this the Right Thing To Do?
The other example modules all suffer from this problem.
Peace, Ben
--
__ _
/ / (_)__ __ ____ __
/ /__/ / _ \/ // /\ \/ / . . . t h e c h o i c e o f a
/____/_/_//_/\_,_/ /_/\_\ G N U g e n e r a t i o n . . .
------------------------------
From: crawford@think.com (Lee Crawford)
Subject: Re: Physical Memory size
Date: Fri, 14 Oct 1994 14:30:02 -0500
In article <37ffii$1n9@galaxy.ucr.edu>, cdematt@corsa.ucr.EDU (Cheryl
Dematteis) wrote:
>
> Is there a system call which returns the number of pages of physical memory a
> system has ?
You should be able to get it by opening the core image device (I don't
remember the name of it, /dev/kmem or /dev/mem or something like that.) and
then lseek'ing to the end and then looking at what byte offset position
you're at.
Or, open /proc/meminfo and parse it to find out the memory configuration.
> In Solaris, the system call sysconf(_SC_PHYS_PAGES) gives me the number I'm
> looking for. Linux (1.0.9) does not recognize _SC_PHYS_PAGES.
I haven't bothered to look for library support for memory size detection.
> Thanks for the help.
>
> --
> Cheryl K. DeMatteis cdematt@cs.ucr.edu
> Graduate Student (909)787-3432
> Department of Computer Science
> University of California
> Riverside, CA 92521
--
--- Lee Crawford
Thinking Machines Corporation
crawford@think.com
------------------------------
From: c_farer@news.gate.net (Wade Scholine)
Crossposted-To: gnu.gcc.help
Subject: Re: Looking for X graphics/ Plotting libraries
Date: 12 Oct 1994 08:53:24 -0400
CookieMonster <prpatel@isisa.oit.unc.edu> writes:
>I am working on a small project, and need some library routines to do
>some simple X windows graphics: Pop open a window, take some disk data,
>and graph the data in the window with auto-scaling, axis, etc. SInce I
>want to spend more time on the data producing side of the program, I need
>a package that can do the plotting for me.
There is a program called x11-graph which does the trick for me.
It's kinda old (at least the version I have is) but with minor
tweaks it works pretty well. You'd have to archie to find it,
since I don't remember where I got mine (or I suppose I could
mail it to you...)
--
Wade L. Scholine | Once upon a time, four AMPHIBIOUS HOG
c_farer associates, inc. | CALLERS attacked a family of DEFENSELESS,
Delray Beach, FL. | SENSITIVE COIN COLLECTORS and brought DOWN
| their PROPERTY VALUES!!
------------------------------
Crossposted-To: comp.os.linux.help,comp.os.linux.misc
From: rr002c@uhura.cc.rochester.edu (Rajib Rashid)
Subject: * Please help with RPC Error *
Reply-To: rr002c@uhura.cc.rochester.edu
Date: Wed, 12 Oct 94 23:26:57 GMT
Hello:
I have recently installed Linux on my 25MHz pc with 8MB ram, and
everything seems fine, except once in a while I get this error:
mount cleanudp_creat RPC: portmap failure - RPC: Unable to receive
at startup. This prevents me to mount a friends hard drive, from
which I run X :( This does not happen all the time though. I have not been
able to figure out what makes this happen. Does anyone have any idea or
suggestions on why this is happening, and how I can fix the problem?
Thank you very much in advance. Please send your replies to
'rr002c@uhura.cc.rochester.edu'.
Rajib Rashid
University of Rochester
------------------------------
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: A badly missed feature in gcc
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Wed, 12 Oct 1994 12:45:06 GMT
Followup to: <6453@sparky.mdavcr.mda.ca>
By author: bruce@mdavcr.mda.ca (Bruce Thompson)
In newsgroup: comp.os.linux.development
>
> is of dubious merit from a _style_ point of view. HOWEVER, it _is_
> legal according to the ANSI standard. I would argue then that what
> we're discussing is a change to the standard, not a simply a change to
> a particular compiler. As such, it's my opinion that the change should
> be evaluated in that light.
>
> IMHO it still strikes me as a needless modification to the C standard
> since in most cases C++ will look and feel enough like ANSI C that
> simply using C++ should suffice.
>
> As a postscript, I find the notion of supporting multiple comment
> syntaxes as unusual in the extreme. I know of no other language than
> C++ which has multiple comment syntaxes. I have yet to encounter a
> compelling reason for it besides backward-compatability which isn't
> _that_ compelling for me.
>
C++ added another comment convention for the reason that comments
terminated in newline tend to be a *lot* more convenient to use than
C-style block comments. (You may disagree, but I am fairly certain
you are in minority). /* ... */ is supported as backward
compatibility, but you will be hard-pressed to find a C++ programmer
who uses them more than once in a blue moon.
/hpa
--
INTERNET: hpa@nwu.edu --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL HAM RADIO: N9ITP or SM4TKN
FIDONET: 1:115/511 or 1:115/512 STORMNET: 181:294/1 or 181:294/101
#include <sig/virus.h>
------------------------------
From: hpa@ahab.eecs.nwu.edu (H. Peter Anvin)
Subject: Re: Physical Memory size
Reply-To: hpa@nwu.edu (H. Peter Anvin)
Date: Wed, 12 Oct 1994 12:52:10 GMT
Followup to: <37ffii$1n9@galaxy.ucr.edu>
By author: cdematt@corsa.ucr.EDU (Cheryl Dematteis)
In newsgroup: comp.os.linux.development
>
> Is there a system call which returns the number of pages of physical memory a
> system has ?
>
> In Solaris, the system call sysconf(_SC_PHYS_PAGES) gives me the number I'm
> looking for. Linux (1.0.9) does not recognize _SC_PHYS_PAGES.
>
The first number on the second line of /proc/meminfo contains the
number of kilobytes not including kernel reserved memory. The length
of /proc/kcore equals total memory (including kernel reserved) plus
4096.
/hpa
--
INTERNET: hpa@nwu.edu --- Allah'u'abha ---
IBM MAIL: I0050052 at IBMMAIL HAM RADIO: N9ITP or SM4TKN
FIDONET: 1:115/511 or 1:115/512 STORMNET: 181:294/1 or 181:294/101
Unizork: You are in a maze of twisty little directories, all different...
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
You can send mail to the entire list (and comp.os.linux.development) via:
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
Linux may be obtained via one of these FTP sites:
nic.funet.fi pub/OS/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development Digest
******************************
Reference in New Issue View Git Blame Copy Permalink