Files
oldlinux-files/ftp-archives/tsx-11.mit.edu/1996-10-07/mail-archive/linux-devel/Volume2/digest285
2024-02-19 00:24:15 -05:00

530 lines
20 KiB
Plaintext

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: Mon, 10 Oct 94 06:13:07 EDT
Subject: Linux-Development Digest #285
Linux-Development Digest #285, Volume #2 Mon, 10 Oct 94 06:13:07 EDT
Contents:
Re: Compiling progs using port I/O (Brandon S. Allbery)
Re: A badly missed feature in gcc (Michael Edward Chastain)
Re: Improving SLIP latency under Linux (John Richardson)
Re: Serious Bug In The Networking Code (Jerry Ablan)
Re: [fixed] lmail problem with sendmail (Tim Bass (Network Systems Engineer))
code coverage tool for c (Bob Horgan)
Shared library - HOW? (Jinwoo Shin)
Re: Beautifying Linux/Xfree (Maxim Spivak)
Re: Linux For Mac :( (Gary J LaPointe)
Re: Any threads package ? (John Richardson)
windowing/menu and more c lib for linux? (Hans Petter Fasteng)
Re: Shared Libs: working toward a permanent solution? (Bryan Ford)
Re: Multiprocessing Pentium Systems (Bryan Ford)
Re: Unable to find XF86-3.1-lib.tar.gz with correct sum. (Scott McClung)
Generic SCSI stuff (julichjh@RoseVC.Rose-Hulman.Edu)
Just a quick question... (Matthew Richard Scopp)
Re: windowing/menu and more c lib for linux? (Dimitris Evmorfopoulos)
----------------------------------------------------------------------------
From: bsa@kf8nh.wariat.org (Brandon S. Allbery)
Subject: Re: Compiling progs using port I/O
Date: Fri, 7 Oct 1994 16:22:35 GMT
In article <CxAn0w.Co2@pe1chl.ampr.org>, pe1chl@rabo.nl says:
+---------------
| In <1994Oct7.030740.22704@unlv.edu> ftlofaro@unlv.edu (Frank Lofaro) writes:
| >In article <36hm55Ebnr@uni-erlangen.de> bon@lte.e-technik.uni-erlangen.de (Uwe Bonnes) writes:
| >>Rob Janssen (rob@pe1chl.ampr.org) wrote:
| >>> In <36bmo0$fmg@clarknet.clark.net> nardone@clark.net (Joe Nardone) writes:
| >>> >I'm trying to compile a program that uses the inb and outb
| >>> >functions (macros, actually) but when it comes to link time
| >>> You have to compile with optimization (-O2)
| >>Is there some explanation for that behaviour?
| >extern inline is used instead of static inline in the function definitions.
| >This is a Bad Thing. Without optimization, inline is ignored, thus
| and link many modules together, would be to put the functions that are now
| unresolved in the C library as well. A program compiled with no optimization
+------------->8
People are forgetting that user mode programs should not be using direct port
I./O in most cases; that belongs in the kernel. Linux is not MS-DOS. The
current behavior makes a good warning that the person using direct port I/O
shoulod be thinking twice about what they are doing.
Keep in mind aklso that port I/O requires running the program setuid root and
a prior call to ioperm() or iopl(), so that the program can request the
ability to access ports from the kernel. Likewise a hint that the programmer
should think twice about whether they are actually doing things the way they
should be.
++Brandon
--
Brandon S. Allbery KF8NH [44.70.4.88] bsa@kf8nh.wariat.org
Linux development: iBCS2, JNOS, MH ~\U
Daily dreading Nehemiah Scudder^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^HRush Limbaugh
------------------------------
From: mec@shell.portal.com (Michael Edward Chastain)
Subject: Re: A badly missed feature in gcc
Date: 7 Oct 1994 21:15:12 GMT
In article <373vcn$1da@nz12.rz.uni-karlsruhe.de>,
> This would break perfectly correct C code, like
>
> a = b//* Comment here */ c;
So, the compiler could issue a warning when it sees '//*' in the input.
It already issues warnings for other legal but dubious constructs,
such as trigraphs.
Michael Chastain
mec@shell.portal.com
------------------------------
From: jrichard@cs.uml.edu (John Richardson)
Subject: Re: Improving SLIP latency under Linux
Date: 7 Oct 1994 18:55:58 GMT
In article <1994Oct7.161024.20465@unlv.edu>,
Frank Lofaro <ftlofaro@unlv.edu> wrote:
>
[discussion of TOS queueing]
>How about giving packets below a certain size higher priority?
>That would help interactive traffic, and handle cases such as downloads
>though a terminal session properly.
I don't know if that would work all the time... with Nagle's alg
you can get big interactive packets (most likely screen refreshes
etc).
--
John Richardson
jrichard@cs.uml.edu
------------------------------
From: munster@MCS.COM (Jerry Ablan)
Crossposted-To: comp.os.linux.admin,comp.os.linux.help
Subject: Re: Serious Bug In The Networking Code
Date: 9 Oct 1994 19:51:55 -0500
On 9 Oct 1994 18:33:07 GMT, Ketil Z Malde spake thusly:
: There appears to be a serious bug in some of the networking code
: supplied with linux/slackware, that causes the computer to get
: 'network unreachable' after approximately 3 minutes of perfect
: functioning. I have no idea what the problem might be, and if
: somebody tell me where to look, I can try to figure out what versions
: my drivers etc. are. Here are the configurations I ve gotten this
: problem with:
I've noticed that this occurs when you run routed. Do not run routed and see
if it still happens.
-- Jerry
------------------------------
From: bass@cais2.cais.com (Tim Bass (Network Systems Engineer))
Subject: Re: [fixed] lmail problem with sendmail
Date: 9 Oct 1994 22:01:50 GMT
Arnt Gulbrandsen (agulbra@nvg.unit.no) wrote:
: In article <3797ke$ktn@news.cais.com>,
: Tim Bass (Network Systems Engineer) <bass@cais.cais.com> wrote:
: >Looking at the src for lmail.c the code contains the line(s):
: >
: >if (fputs (line,fp) != strlen (line)) { ... }
: >
: >in the source.
: >
: >Doing some detective work yielded that fact that fputs() was always 1 and
: >never equaled strlen() even though the write was okay.
: This bug was reported a long time ago, a year perhaps. Perhaps you
: could upload a fixed version?
I have fixed the lmail.c source by doing;
if (fputs(line,fp) < 0) { ... }
(in two places in the code, BTW) Simple fix really.
This is my first linux 'fix'. What should I do about this?
My first guess is to upload the source to an ftp site and
announce it c.o.l.a group. Is this right?
: The problem is really that the successful return value of fputs() and
: puts() isn't specified. The man pages I have say it should return
: EOF and -1 (EOF is, I hope, -1) on error, but don't say anything
: about success.
: --Arnt
------------------------------
From: jrh@platte.bellcore.com (Bob Horgan)
Subject: code coverage tool for c
Date: 7 Oct 1994 20:01:25 GMT
The code coverage tool, ATAC, is available via ftp from Bellcore.
ATAC is a C-language test coverage analysis tool developed at Bellcore by
Bob Horgan and Saul London. ATAC measures how thoroughly a program is tested
by a set of tests using data flow coverage techniques, identifies areas that
are not well tested, identifies overlap among tests, and finds minimal covering
test sets. ATAC has been used extensively in Bellcore research and development
and at several universities for both education and research. ATAC has been
ported without changes to many UNIX (TM) platforms including linux and
the following trade-marked systems: BSD, System V release 3, SunOS 4.1, Solaris,
Pyramid OSx, ULTRIX V4.2, HP-UX 9.0, AIX 3.2, UTS. ATAC's source code browser
is based on termcap or terminfo. X is not required for this version of ATAC.
To ftp ATAC:
1. ftp anonymously to flash.bellcore.com.
2. Change directory to atac
3. Read the README.
It is important to us to know who is interested in ATAC. If you ftp
ATAC and are interested in keeping up with or improving ATAC, please
mail to atac@bellcore.com.
------------------------------
From: jwshin@nitride.EECS.Berkeley.EDU (Jinwoo Shin)
Subject: Shared library - HOW?
Date: 8 Oct 94 09:19:22 GMT
Can someone tell me the details of Linux shared library stuffs? Like how to
create a shared library with gcc? If there is a faq for this, I couldn't find
one.
--
Jinwoo Shin jwshin@eecs.berkeley.edu
System Administrator
Berkeley Sensor and Actuator Center
------------------------------
From: maxims@ucsee.EECS.Berkeley.EDU (Maxim Spivak)
Crossposted-To: comp.os.linux.misc
Subject: Re: Beautifying Linux/Xfree
Date: 7 Oct 1994 17:53:35 GMT
In article <373rrl$19kq@fidoii.cc.lehigh.edu>,
DAVID L. JOHNSON <dlj0@Lehigh.EDU> wrote:
>In article <372tg0$1ai@huron.eel.ufl.edu>, acg@kzin.cen.ufl.edu (Alexandra Griffin) writes:
>>In article <1994Oct5.141142.773@muvms6>,
>>Andy Bailey <bailey9@muvms6.wvnet.edu> wrote [in c.o.l.misc]:
>>>[...]
>>>
>
>This is arleady avialable. Try GREAT. Really. It takes a while to
>configure, and you should have Motif to get the best performance, but it has
>lots of options.
How is GREAT`s performance now? I tried .90 with static Motif, and it was
_slow_ on an 8 MB machine. I do have Motif libs now, and also have 16 MB
of RAM, but will it slow the machine to a halt if I load it up and open
an emacs as well?
Max
--
**************************************************************************
Maxim Spivak | #include <GoBears.h>
University of California, Berkeley | #include <StdDisclaimer.h>
maxims@ucsee.eecs.berkeley.edu | #include ".signature"
------------------------------
From: gary@ah3.cal.msu.edu (Gary J LaPointe)
Subject: Re: Linux For Mac :(
Date: 8 Oct 1994 12:16:35 GMT
LINUX ON POWER MAC DELAYED AS I/O PROBLEMS & COLLEGE WORK INTERVENE
(October 7th 1994) The amateur development work to port the Linux
version of Unix to the Power Macintosh has stalled. Back in May
(Issue 5 story 1054), two students, Charlton Wilbur and Jem Lewis,
laid out their ambitious plans to get the Freeware Unix clone up and
running on Apple's machines by September.
Lewis admits that finding spare time is a problem. However he said
this week: "Our biggest problem besides time right now is that the
Power Mac I/O stuff is a proprietary technology, and Apple's not
telling." He adds that they are trying to "cajole" the necessary
information from Apple and are also looking at how to reverse
engineer the chip.
Lewis says that the pair are still plodding on with the project;
"When we think we have a handle on what's going to happen with the
Mac I/O stuff, we'll send a note with a revised schedule", he said.
------------------------------
From: jrichard@cs.uml.edu (John Richardson)
Subject: Re: Any threads package ?
Date: 9 Oct 1994 01:02:12 GMT
In article <Cx7tCq.86L@taligent.com>,
David Engberg <dave_engberg@taligent.com> wrote:
>In article <36ujao$v8@mark.ucdavis.edu>
>leb@cs.ucdavis.edu (Bich-Cau Le) writes:
>
>> I'm doing real-time OS simulations under Unix. Is there something
>> similar to Sun's lightweight process library for Linux?
>
>An implementation of Posix threads (pthreads) is available via
>ftp from bloom-picayune.mit.edu ... the author has information
>available: http://www.mit.edu:8001/people/proven/home_page.html
>
>Has anyone used this on Linux? I would like to write some software
>that would be greatly simplified with a threads library, and I'd
>love to hear your experiences with this one...
I have used previous versions with a pretty good success rate.
The only problem is that the reentrant library isn't 100% done
yet and I keep hitting network functions that haven't been
implemented yet...
--
John Richardson
jrichard@cs.uml.edu
------------------------------
From: hansf@kfdata.no (Hans Petter Fasteng)
Subject: windowing/menu and more c lib for linux?
Date: Sun, 9 Oct 1994 19:37:25 GMT
Is is made a c lib for gcc with functions for making window handling and
menus? if yes where can I get it?
-Hans
------------------------------
From: baford@cs.utah.edu (Bryan Ford)
Subject: Re: Shared Libs: working toward a permanent solution?
Date: 9 Oct 1994 19:19:05 GMT
Richard Krehbiel (richk@netcom8.netcom.com) wrote:
>hpa@ahab.eecs.nwu.edu (H. Peter Anvin) writes:
>> Well, it seems to me there should be a way of handling this using a
>> segment register, instead of wasting a general-purpose register. Set
>> up a local descriptor table, then use the base of a currently unused
>> segment register (GS, for example), then do any references with
>> respect to GS. This doesn't solve the cases where a pointer needs to
>> be passed, of course, but I presume that is not the majority of cases,
>> and this would free up EBX.
>There are definitely problems with pointer conversion; you cannot
>simply interrogate the FS register to find it's base addess, you have
>to look at the MMU table entries, and they're in protected kernel
>space, so you'd need a system call, etc. Plus it would require a
>change to the compiler to generate code that used, say, FS:offset
>addressing for library data. I suspect the frequency of the pointer
>conversions required would kill performance to a far greater degree
>than PIC would.
Assuming the base of this segment register always points
to, say, the base of the library's data segment, just stash
a copy of that actual base pointer in a global library variable
just after loading the library. Then the library uses %gs:offset
to access global variables as proposed, and to convert a pointer,
just 'addl %gs:__libbase,%eax' or whatever. One instruction - big deal.
A potentially bigger problem is saving, setting up, and restoring
that segment register. Since a process may use many libraries
each with a different base, the segment register must be shared,
and loading a segment register takes mucho cycles. It could be done
either in the public library entrypoints, so the register would always
be loaded when entering the library but wouldn't have to be reloaded
during private calls within that library; alternatively it could
be done only in the entry/exit code of functions that access local
variables, making calls to simple library functions faster but possibly
causing unnecessary reloads during intra-library calls.
On the other hand, these segment register loading costs may be
comparable to the costs of figuring out the library base address
and setting up the ebx register in conventional PIC. How much
does a jbsr-to-next-instruction and the other related glop cost now?
In any case, I just wanted to point out that this idea may be worth
looking into a little more. If the idiocy of the x86 architecture
makes conventional PIC slow, I see no reason not to take advantage
of a "feature" of same architecture to counteract that effect. :-)
Bryan
---
Bryan Ford baford@cs.utah.edu University of Utah, CSS
`finger baford@schirf.cs.utah.edu' for PGP key and other info.
------------------------------
From: baford@cs.utah.edu (Bryan Ford)
Subject: Re: Multiprocessing Pentium Systems
Date: 9 Oct 1994 19:35:23 GMT
Alan Cox (iialan@iifeak.swan.ac.uk) wrote:
>Linux reflects the hardware people posess - thats one thing thats good about
>it - you can run it on a 4Mb 386SX, you can use old MFM drives , you can
>use 360K floppies. You can run X on a herc card. Until a bunch of Linux
>hackers have a multicpu pentium board and relevant documentation nothing
>will happen. So the people who want it can either
>1) Buy a machine and do the job
>2) Buy a machine and donate it to someone in exchange for doing the job.
I agree, and would like to point out that anyone can get a very nice, complete
dual-486DX2/66 MP machine from VTech for well under $4000, including all
the standard stuff PCs generally come with and then some. (The research
group I'm in just got one for Mach development; I highly recommend it.)
You don't need Pentiums to do MP OS development, although these machines can
be gotten in dual-Pentium versions of you want to shell out a little more.
On the other hand, I would suggest that anyone with serious MP interest
buy an MP as Alan suggested, but then join the Linux-on-Mach project.
Mach already has MP support, and a quite useable free Mach OS server
with Linux personality support is already available and rapidly improving.
Apologies if the people on this thread have already heard this plug... :-)
Bryan
---
Bryan Ford baford@cs.utah.edu University of Utah, CSS
`finger baford@schirf.cs.utah.edu' for PGP key and other info.
------------------------------
From: mcclung@owens.ridgecrest.ca.us (Scott McClung)
Subject: Re: Unable to find XF86-3.1-lib.tar.gz with correct sum.
Date: Sun, 9 Oct 1994 23:40:17 GMT
In article <379o5j$f79@charles.cdec.polymtl.ca>,
Pierre Belanger <belanger@info.polymtl.ca> wrote:
>Kevin Ruland (kevin@rodin.wustl.edu) wrote:
>
>: I've searched the world over to find the X11R6 libs and can't find one
>: with the correct checksum. gunzip even pukes on it. It seems okay
>: up to ./lib/libX11.so.6
>
>: I've tried the following sites:
>
>: xfree86.cdrom.com
>Either you don't ftp with "bin" option 'enable' or you must do something
>wrong. I HAD NO PROBLEM AT ALL.
Wrong. I had exactly the same problem with XF86-3.1-lib.tar.gz. Someone
was kind enough to upload a corrected file, though, and it uncompresses
fine.
--
/* Scott McClung Opinions expressed here are mine.
* Software Engineer/System Admin
* mcclung@imt.saic.com
* mcclung@ridgecrest.ca.us
*/
------------------------------
From: julichjh@RoseVC.Rose-Hulman.Edu
Subject: Generic SCSI stuff
Date: 3 Oct 1994 17:57:46 GMT
Reply-To: julichjh@RoseVC.Rose-Hulman.Edu
We have CDWRITE and would like to write CDR's on our Phillips CD-WRITER.
supposedly our hardware is supported. The generic devices are created..
BUT I can't get a valid inquiry out of CD-WRITER. I did patch the scsi
code to allow the worm drive to come up as a ROM drive and that worked.
That is unpatched now. but still no worm access... What do I need to do
to set up the generic driver to allow generic scsi access to the worm drive
Joe Julicher
------------------------------
From: gt4374c@prism.gatech.edu (Matthew Richard Scopp)
Subject: Just a quick question...
Date: 8 Oct 1994 01:25:07 -0400
Hello. I have a quick question. I'll apologize in advance if this
is a question that is constantly being asked, but I have just joined this
group this very minute, and it takes far too long to wade through over 1500
articles looking for what I need. :) I was just wondering what the status
of Linux development is for the PowerPC chip. Specifically, if I go out and
buy myself a PowerMac, will I be able to run Linux on it any time soon, or
will I grow a big grey beard first? I'm just curious as to what kind of
support for PowerMac Linux there is. I don't think I would be able to run
XFree86 :) so I'd have to look elsewhere. They're supposed to be porting AIX
to PowerPC, but AIX is a joke that's not worth laughing at. PowerPCs seem
like good chips to run Linux on, so I'm hopeful about possible support. Thanks
for your time. My e-mail address is gt4374c@prism.gatech.edu.
- /|/|att Scopp
--
Matt Scopp
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt4374c
Internet: gt4374c@prism.gatech.edu
------------------------------
From: dimitris@myhost.subdomain.domain (Dimitris Evmorfopoulos)
Subject: Re: windowing/menu and more c lib for linux?
Date: 10 Oct 1994 04:39:31 GMT
Hans Petter Fasteng (hansf@kfdata.no) wrote:
: Is is made a c lib for gcc with functions for making window handling and
: menus? if yes where can I get it?
: -Hans
For terminals try ncurses, for X, ... well there are plenty of ways.
--
______ _______
| __ \ | _____| devmorfo@interaccess.com Dimitris Evmorfopoulos
| | \ | | |___ (312)-296-6034
| | | | | ___|
| |___| | | |_____ I saw a GNU Hurd once !. There were lots of
|_______| * |_______| * little GNU's running all together like crazy.
------------------------------
** 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
******************************