lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory mail-archive

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:25:02 -05:00
parent 07129c3397
commit a778c607a4
1056 changed files with 796887 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

650
mail-archive/linux-devel/Volume1/digest5XX/digest570 Normal file
View File

@@ -0,0 +1,650 @@
Subject: Linux-Development Digest #570
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: Tue, 22 Mar 94 03:13:22 EST
Linux-Development Digest #570, Volume #1 Tue, 22 Mar 94 03:13:22 EST
Contents:
ncurses !working under serial terminal (maizeli@md2.huji.ac.il)
Re: Driver for precise delays: Driver etiquette? (Alan Cox)
Ext2fs secure rm bug (?) plus ideas for improvement (Frank Lofaro)
Re: ircII2.2.9 Problems (Joonwoo Nam)
Re: blank_screen patch for Laptops (Questions) (Christoph Rimek)
Which ether card (Francois Fabre)
Re: Linux for Sun4 (Hamish Macdonald)
RARP misdefined in if_ehter.h (Paul Fox)
Re: rarpd done? berkeley packet filter? (Florian La Roche)
Re: How to write a device driver (Wolfgang Schelongowski)
Re: Mapping the text screen into user space (i.e. KDMAPDISP, mmap, etc): SOLVED!!!! (Mahesh Neelakanta)
Re: RARP misdefined in if_ehter.h (Paul Fox)
Re: I'm developing UMSDOS Linux Pkg. (Peter Busser)
Networking Issues (shortcomings?) (Edward Barron)
Re: I'm developing UMSDOS Linux Pkg. (tad)
e2fs crash from bash script (Ted Deppner)
Re: Problem with V1.0 Ne*000 probe (Christer Weinigel)
Has lpd/lpr been fixed for lpr -p ? (randall kevin sharpe)
----------------------------------------------------------------------------
Subject: ncurses !working under serial terminal
From: maizeli@md2.huji.ac.il
Date: 20 Mar 94 22:38:43 IST
I am having problems with running ncurses-based application from a serial
terminal. Using the very same environement (both TERM=vt100) it works from the
console but not the terminal; There is simply generates floating point fault.
I traced the problem into a call to mvcur(0,0,0,0) which seems to cause the
problem, as when I run it from the console the call is mvcur(0,0,1,0).
Thanks in advance, Yossi.
------------------------------
From: iiitac@uk.ac.swan.pyr (Alan Cox)
Subject: Re: Driver for precise delays: Driver etiquette?
Date: Sat, 19 Mar 1994 13:36:58 GMT
In article <1994Mar16.230728.7469@cc.gatech.edu> byron@cc.gatech.edu (Byron A Jeff) writes:
>1) As I asked the last time what will be the effect of having uninterruptable
> 100 uS delays for the rest of the system? Will anything break? The max
> delay I saw in any other driver was 30 uS.
The PLIP (parallel port IP) driver occasionally goes into the 100uS delay times.
Its not a good idea in general use. You'll drop serial characters and will get
possible network card overruns also.
>2) Do kernel space routines usually run with interrupts masked or unmasked?
Unmasked.
>
>3) If I cli() is there any exception in normal use that will interrupt a
> process that is running between a cli() and an sti()?
Only a non maskable interrupt, and those are normally memory failures (ie parity)
A few laptops use NMI for power saving controls - you have been warned 8-)
>
>- doing a write will activate a hardware line on my programmer card,
> delay for 100 uS, then deactivate the hardware line.
>- The activation, delay, and deactivation will be done atomically by
> turning off interrupts.
>
>- Use one of the PC hardware timers. the 8254 (or equivalent) has 3 timers.
> Does Linux use all three? If not can I intercept one, program it for 100 uS
> delays and generate an interrupt. However latency could be a problem because
> that line needs to be activated for 100 uS +- 5 uS. Otherwise I get magic
> smoke from my devices ;-)
This is one approach. Linux uses at least one time for the usec clock accuracy.
If you are worried about the 100uS +/- not very many you obviously interrupt at
say 70uS and then busy wait the last few. Bear in mind that an IDE disk I/O
especially with the multi-block patches can knock you over a 100uS out easily.
>
>- Instead of using the hardware timers to spcify the delay, use them to
> give the inter-write delay. So a write would do a uninterruptable usleep
> between wiggling the hardware line followed by a interruptable sleep after
> turning on the timer that will interrupt after 400 uS or so. Since the
> inter-write time is not critical if it's late (due to interrupt latency)
> it's no problem.
This sounds quite feasible. I assume you are not intending to have 16 people
playing games and writing essays on the machine at the same time. If not then
it'll feel slightly icky but no worse.
>
>Anyway I'm thinking that this might be a good example of a simple (very
>simple) device driver and can show the minimal elements needed for a
>device driver.
It sounds like a far from simple example!!!
>
Alan
------------------------------
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Ext2fs secure rm bug (?) plus ideas for improvement
Date: Mon, 21 Mar 94 01:15:39 GMT
I was looking at the ext2fs code and found something weird.
The secure rm attribute on ext2fs files is only referenced in
fs/ext2/truncate.c and not in fs/ext2/namei.c (which contains unlink).
The ext2_unlink does not seem to call any trucation functions (as far
as I can tell). Thus it seems that truncates will securely delete
blocks (by covering them up with random junk), but an unlink will
NOT. Once the last link to a file with secure rm enabled is deleted,
the secure rm algorithm should be used. Or does ext2fs do this, and
I'm not seeing it? Should I add a call to ext2_truncate right before
unlink unlinks the last reference?
Also, I am thinking of an enhancement for secure rm. Overwrite
with all ones, then all zeros, then random junk, then default info
(i.e. what would be there if that part of the fs was never used).
This would make it hard for data to be recovered by those that have
the hardware to read data that was been written over once. Allowing
multiple passes would be nice too. Like the wipedisk program of Norton
Utilities (TM) does (although it does not ever write random data, if I
remember correctly :| )
------------------------------
From: nam@risky.ecs.umass.edu (Joonwoo Nam)
Subject: Re: ircII2.2.9 Problems
Date: 21 Mar 1994 01:44:47 GMT
Paul Gray (pgray@saucer.cc.umr.edu) wrote:
: I am having problems compiling IRCII2.2.9 on my linux. I am using
: slackware distribution, linux vers 0.99.15.
: I have already changed LEX = FLEX
: lexlib =
: So its not those common problems. I get an undefined symbol error.
: (yywrap undefined symbol) Its in count.c, which is the first file it
: tries to compile so maybe something is just set wrong. Does anyone have
: any ideas?
: -PJ
: --
: ---------------------------------------------------------------------
: Paul J. Gray pgray@umr.edu
: University of Missouri-Rolla
First of all, This would rather be posted to comp.os.linux.help.
You should specify :
lexlib=libfl.a
flex is a part of slackware distribution and included in d2 disk.
Joon
=====================================================================
Joonwoo Nam nam@nazgul.ecs.umass.edu
Dept. of Electrical and Computer Engineering
University of Massachusetts at Amherst
=====================================================================
------------------------------
Date: 21 Mar 1994 12:55:00 +0100
From: chrimek@rimki.toppoint.de (Christoph Rimek)
Subject: Re: blank_screen patch for Laptops (Questions)
Reply-To: chrimek@tpki.toppoint.de
Hello
63912i@cfi.waseda.ac.jp wrote on 17.03.94:
> After a horrible trip with sourcer through a DOS device driver
> for my laptop, I got my new 1.0 to switch off the backlight for
> the LCD screen in blank_screen() and back on again in unblank.
> So far, so good.
> [...]
This (and the deleted other stuff) leads me to the idea to alter the
screen blanking code in a way, that supports not only any laptops' screen
blanking function but also the power saving function of the new monitor
generation according to TCO91 and TCO92.
Personally I have a Smile 1506, and this monitor has the power save
feature labelled "Energy Star - EPA Pollution Preventer".
For DOS operation Smile has the small programm EM.COM which I lately
disassembled but did not have the time to fully comment. It does some
port-I/O (polarity switching of HSYNC/VSYNC) to signal the blanking
request to the monitor, which then activates its local power save feature
(Standby Mode).
The monitors' power consumption is shut down to somewhere around 3 Watts!
-cr
--
Christoph Rimek, Kiel, Germany (+49 431 18307) chrimek@toppoint.de
## CrossPoint v2.93 ##
------------------------------
From: ffabre@droopy.laas.fr (Francois Fabre)
Crossposted-To: comp.os.linux.help
Subject: Which ether card
Date: 21 Mar 1994 14:29:55 GMT
Hi !
I am planning to buy (2) ethernet cards (slip is a bit slow !).
But I was wondering which one beetween :
Eagle NE100
Allied Telesis 1500
Allied Telesis 1700
Please, could you help me ?
PLEASE ANSWER TO chaput@ensica.fr
------------------------------
From: Hamish.Macdonald@bnr.ca (Hamish Macdonald)
Subject: Re: Linux for Sun4
Date: 21 Mar 1994 14:05:22 GMT
>>>>> "Dominik" == Dominik Kubla <kubla@goofy.zdv.Uni-Mainz.DE> writes:
Dominik> But given the difficulties the various m68k ports have, i doubt that you
>>>>> gunnarr@ifi.uio.no (Gunnar Rxnning) wrote:
Gunnar> What difficulties ?
Yeah, I'd be interested in knowing the difficulties I've been having,
too..
------------------------------
From: pgf@cayman.com (Paul Fox)
Subject: RARP misdefined in if_ehter.h
Date: 21 Mar 1994 16:34:06 GMT
to save others the same tedium i endured yesterday trying to figure out
why my RARP code didn't work, i'm reporting a bug (i'm running pl13, don't
know if it's fixed in 1.0). the #define for the RARP protocol type
is incorrect -- it says 0x0835 -- the correct value is 0x8035.
paul
--
=====================
paul fox, pgf@cayman.com (cayman systems inc. in heavenly woburn, ma)
home: pgf@foxharp.boston.ma.us (arlington, ma)
------------------------------
From: rzsfl@sbusol.rz.uni-sb.de (Florian La Roche)
Subject: Re: rarpd done? berkeley packet filter?
Date: 21 Mar 1994 20:30:01 GMT
About RARPD and BPF:
- That packet filter is already included in an old ported version of tcpdump.
Fetch a new one from 134.96.7.7:/pub/Linux/source/networking/NetBSD/tcpdump*
I had a quick look at it, but didn't fix many things. The calling semantics
for newer versions have changed, so the Linux support in "tcpdump" has to be
changed. (probably only a little bit.)
(And most probably don't look at my changes, but start from scratch...)
- As Alan has already said, take the NetBSD rarpd and write a Makefile. All
further changes should be minimal.
Florian La Roche
------------------------------
From: ws@xivic.bo.open.de (Wolfgang Schelongowski)
Subject: Re: How to write a device driver
Date: 21 Mar 1994 12:47:59 +0100
In <2mh667INNko@charnel.ecst.csuchico.edu> chafey@ecst.csuchico.edu (Chris Hafey) writes:
>In article <CMwsr1.5uE@jaxnet.com>, <root@jaxnet.com> wrote:
>>I am an experienced applications programmer and I would like to learn how to
>>write a device driver for Linux. Can anyone recommend a book that will
>>help me get started. I have written a serial device driver for DOS so I
>>think I am up to the challenge but I need a book to learn from. A book
>>on operating systems (how to build) would also be great.
>An ok book which I have used is:
>Writing a Unix Device Driver
>Janet I Egan & Thomas J Teixeira
>Publisher: John Wiley & Sons (wiley)
>ISBN 0-471-53574-5
[important caveats deleted]
Read
> From: sko@wimsey.bc.ca (Samuel Ko)
> Newsgroups: misc.books.technical, ... ,news.answers
> Subject: [misc.books.technical] A Concise Guide to UNIX Books
> Summary: A list of recommended books and documents on Unix and related areas
...
>Archive-name: books/unix
and you'll find (among other useful books):
23. Title: Writing Unix Device Drivers
Authors: George Pajari
Publisher: Addison-Wesley
Edition: 1992
ISBN: 0-201-52374-4
Comment: An easy-to-understand book covering character, block, terminal,
and stream drivers ...
That posting is archived on rtfm.mit.edu, of course.
--
Wolfgang Schelongowski ws@xivic.bo.open.de
"Hi, Bill. You sound a bit depressed to me."
"It's worse than that. I'm dead, Jim."
-- Terry Pratchett, Johnny and the Dead
------------------------------
From: mahesh@sendai.seq.com (Mahesh Neelakanta)
Subject: Re: Mapping the text screen into user space (i.e. KDMAPDISP, mmap, etc): SOLVED!!!!
Date: Mon, 21 Mar 1994 18:23:50 GMT
>Mahesh Neelakanta (mahesh@sendai.seq.com) wrote:
>
> sometimes the program doesn't write anything to the screen at all. This
> is reproducible especially when the cursor is at the bottom of the screen.
>
Thanks to everyone who responded to my question! Here is the basic summary
of my problem and it's solution.
Problem: 1) Direct screen writes to the text screen don't always work after
mmap'ing the video memory into userspace. 2) Free'ing mmap'd area
causes a seg-fault.
Solution: 1) Linux's scrolling code modify the starting address of the video
memory so that it can do smooth scrolling. Therefore, the
starting address is not always 0xB8000. The code below shows how
to get the offset which should be added to 0xB8000. 2) use munmap()
to unmap memory or just let linux do the job when your program exits.
Which leads me to one final question: Can someone explain why the '<< 1' is
needed in the code fragment below? My guess is in the comments below which
I figured/guessed/voodoo by reading around in console.c.
Again, Thanks to all who answered,
mahesh
/* Cut here */
/* This code snipet get's the offset into the video memory which can be */
/* used (by adding to base address ...0xB8000) for direct screen writes */
#include <stdio.h>
#include "vga.h" /* see svgalib's vgamacros.h...needed for inb & outb */
/* inlines */
#define CRT_IC 0x3D4 /* Index register */
#define CRT_DC 0x3D5 /* Data register */
main()
{
GetScreenOffset();
}
GetScreenOffset()
{
short offset;
int hi, lo;
iopl(3); /* Get io priv's so we can write to CRTC */
ioperm(CRT_IC, 1, 1);
ioperm(CRT_DC, 1, 1);
outb(CRT_IC, 12); /* High-byte */
hi = inb(CRT_DC);
outb(CRT_IC, 13); /* low-byte */
lo = inb(CRT_DC);
offset = lo | (hi << 8);
offset <<= 1; /* Why? Because this is not seg:offset anymore */
/* but rather flat memory...right?? */
printf("offset = 0x%x (%d)\n", offset, offset);
return offset;
}
------------------------------
From: pgf@cayman.com (Paul Fox)
Subject: Re: RARP misdefined in if_ehter.h
Date: 22 Mar 1994 00:29:16 GMT
I wrote:
: know if it's fixed in 1.0). the #define for the RARP protocol type
: is incorrect -- it says 0x0835 -- the correct value is 0x8035.
i've been told this has been fixed. okay. i guess i should upgrade. but
it _works_ now. :-)
=====================
paul fox, pgf@cayman.com (cayman systems inc. in heavenly woburn, ma)
home: pgf@foxharp.boston.ma.us (arlington, ma)
------------------------------
From: peter@globv1.hacktic.nl (Peter Busser)
Crossposted-To: comp.os.linux.misc
Subject: Re: I'm developing UMSDOS Linux Pkg.
Date: Mon, 21 Mar 1994 14:21:29 GMT
jmorris@darkstar.rastek.com (Jim Morris) writes:
>I believe that he requires you to have 8MB or RAM to install with UMSDOS,
>because if your hard disk is formatted for DOS, odds are you are not going to
>be able to create a swap partition for the install process to use.
What about a swap file?
Groetjes,
Peter Busser
------------------------------
From: barron@woowoo.tiac.net (Edward Barron)
Crossposted-To: comp.os.linux.admin
Subject: Networking Issues (shortcomings?)
Date: 21 Mar 1994 23:22:59 GMT
I've just finished putting my Linux box on the internet, and I've noticed
a couple of problems/shortcomings with the networking code. I was
wondering if someone could let me know if there are workarounds or
if people are working on addressing them in future releases.
tcp.c: tcp_data memory leak detected.
This one seems pretty obvious. I reproduce this one pretty easily,
when getting news.
The second problem is related to the first. I don't seem to be able to
get larger (>30K) files news articles across the wire. I've telneted
by hand to the nntp port and tried grabbing the article, and the tail
end of it gets lost (along with the termination character). This
problem only occurs on linux systems, so I'm guessing theres some
sort of buffering problem on telnet connections when lots of
data gets sent?
Thanks,
please respond to barron@uisinc.com
-Ed Barron
barron@uisinc.com
------------------------------
From: tad@iastate.edu (tad)
Crossposted-To: comp.os.linux.misc
Subject: Re: I'm developing UMSDOS Linux Pkg.
Date: 22 Mar 94 05:03:18 GMT
In <1994Mar21.142129.14283@globv1.hacktic.nl> peter@globv1.hacktic.nl (Peter Busser) writes:
>jmorris@darkstar.rastek.com (Jim Morris) writes:
>>I believe that he requires you to have 8MB or RAM to install with UMSDOS,
>>because if your hard disk is formatted for DOS, odds are you are not going to
>>be able to create a swap partition for the install process to use.
>What about a swap file?
>Groetjes,
>Peter Busser
I just used fips09 to non-destructively create a swap partition at the end
of my drive. It worked for me.
--
tad
tad@iastate.edu
------------------------------
From: tdeppne@eis.calstate.edu (Ted Deppner)
Subject: e2fs crash from bash script
Date: 21 Mar 1994 09:17:10 -0800
this is a bug/is it a bug? report.
file 'a'
--
bash a&
bash a
--
start with "bash a" When this is run as root, it will crash my system.
The error comes up as somthing like "kernel panic, unable to read/write
superblock". There were virtually no "bash: unable to fork" messages, the
machine simply locked being able to start a new process. VC switching
still functioned. I was able to send the "echo >a" that will ususally
terminate a script like this, the system never recoverd. ( I tried this
twice to be sure it was repeatable. first time, it corrupted the e2fs
superblock, and I didn't let it even try to sync the second time )
I run compaq 485dx50, 64mb, 2.1gig Fast SCSI, adaptec 1542 clone
(lanstor), ATI 1024 SVGA, and kernel v1.0. I just tried this wonderful
stript as a "normal" user and it was handeled correctly.
I'm not sure if this would be a kernel bug, or an e2fs bug. I'd be
willing to repeat this and get some hard values if that would help!
--
Ted Deppner
tdeppne@eis.calstate.edu
------------------------------
From: y93chrwe@odalix.ida.liu.se (Christer Weinigel)
Subject: Re: Problem with V1.0 Ne*000 probe
Date: Tue, 22 Mar 1994 05:18:46 GMT
jvoosten@compiler.tdcnet.nl (J.S. van Oosten) writes:
>Hmm, we have problems with the detection of our NE2000 card as well (on all
>version we've had so far). It will always report the right IO-address & IRQ,
>but the probe for the hardware address sometimes fails with something like
>this:
> NE2000 probe failed: 00 40 40 e9 e9 00.
>While the actual address is 00 40 e9 29 cc 67. Seems like somehow the bytes
>get doubled. I suspect a timing problem here (reading the bytes too fast),
>although the machine is just a 386SX16. Only a hard reset brings it back
>again (sometimes). It's particularely irritating because when the probe
>fails, ifconfig also fails and all the utilities that require an interface
>with the local address don't work anymore (telnet, talk, named, etc.).
>: It just hangs immediately after the `Net2 debugged' messages.
I've written a patch which solves this problem on my machine, apparently the
card has to be reset before one tries to read the on board registers.
Oh well, here it is... try at your own risk.
*** linux.old/drivers/net/ne.c Fri Feb 18 10:18:30 1994
--- linux/drivers/net/ne.c Wed Mar 2 01:40:34 1994
***************
*** 123,128 ****
--- 123,134 ----
printk("NE*000 ethercard probe at %#3x:", ioaddr);
+ /* reset card -- wingel 940301 */
+ {
+ int tmp = inb_p(ioaddr + NE_RESET);
+ outb_p(tmp, ioaddr + NE_RESET);
+ }
+
/* Read the 16 bytes of station address prom, returning 1 for
an eight-bit interface and 2 for a 16-bit interface.
We must first initialize registers, similar to NS8390_init(eifdev, 0).
/Christer Weinigel
------------------------------
Crossposted-To: comp.os.linux.help
From: sharpe@sparc12.cs.uiuc.edu (randall kevin sharpe)
Subject: Has lpd/lpr been fixed for lpr -p ?
Date: Mon, 21 Mar 1994 17:30:50 GMT
Has lpd/lpr been fixed for the switch lpr -p for filtering the document
through pr ? Last FAQ/DOC/MANpage I saw it hadn't but I haven't upgraded
lpd lately. Email me at the below address. No Flames Please.
Randy Sharpe
sharpe@cs.uiuc.edu
------------------------------
** 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
******************************