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

604
mail-archive/linux-devel/Volume1/digest5XX/digest576 Normal file
View File

@@ -0,0 +1,604 @@
Subject: Linux-Development Digest #576
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, 25 Mar 94 03:13:11 EST
Linux-Development Digest #576, Volume #1 Fri, 25 Mar 94 03:13:11 EST
Contents:
Re: Afserver for Transputer under Linux ??? (Gerrit Nieuwenhuizen)
Re: probs with ide drive identification (Mark Lord)
Xterm problem w/ 1.0 (bryan wright)
tcpdump: why is the -p flag reversed in meaning? (Paul Tomblin)
Re: Printer Problems -- ANSWERS (Pete Keyes)
Afserver for Transputer under Linux ??? (Kai Dittmann)
Re: Proposal - Coordinating bug fixes with enhancements. (J.S. van Oosten)
Re: GOD SPEAKS ON LINUX! (-J.P.A.Vierinen-)
Re: <stddef.h> in libc-4.5.21? (Christer Weinigel)
Re: Interrupts?? (Timo Giesselmann)
PTY bug? (Daniel S. Ridge)
Re: Proposal - Coordinating bug fixes with enhancements. (John Plocher)
Re: LINUX port to a transputer system (Frank Gleason)
----------------------------------------------------------------------------
From: nieuwhzn@dxgsia.cern.ch (Gerrit Nieuwenhuizen)
Subject: Re: Afserver for Transputer under Linux ???
Date: Thu, 24 Mar 1994 12:57:45 GMT
The most recent version I could find with archie was on
alf.uib.no in directory /pub/Linux/kernel and is called
transputer-04.tar.gz.
Have fun and let the net know if there are any new developments.
I'm especially interested in the gcc port someone talked about.
This could trigger me to get my own transputer system (formerly
hooked up to an Atari ST) going again.
Greetings, Gerrit
Gerrit J. van Nieuwenhuizen
CERN-PPE-IO
Building 595, R-004
CH-1211 Geneve 23
Switzerland
nieuwhzn@dxgsia.cern.ch
(or NIEUWHZN@VXWA80.CERN.CH)
tel.: +41 22 767 4740
fax : +41 22 782 4897
------------------------------
From: mlord@bnr.ca (Mark Lord)
Subject: Re: probs with ide drive identification
Date: 24 Mar 1994 18:51:24 GMT
In article <2m25raINNj54@mailhost.uni-koblenz.de> rausch@informatik.uni-koblenz.de writes:
>as I'm currently working on the IDE driver for Linux 68k, I've faced a
>problem with the 'identify' command; I'm using this (optional) command
>to gather cyl/head/sectors information from the drives, but I've not yet
>managed to extract the drive's name/revision etc. The docs I have say
>it's just plain ascii data, but that seems to be wrong ...
Take a look at my "IDE Performance Package" -- it includes code that
issues and interprets/displays the drive identification thingie.
The text strings returned are in "BIG-endian" byte order, and the drive-name
in particular is sometimes right-justified (40 char field) rather than
left justified.
Here is a code extract:
+#if VERBOSE_DRIVEID
+
+char *cfg_str[] =
+{ "", " HardSect", " SoftSect", " NotMFM", " HdSw>15uSec", " SpinMotCtl",
+ " Fixed", " Removeable", " DTR<=5Mbs", " DTR>5Mbs", " DTR>10Mbs",
+ " RotSpdTol>.5%", " dStbOff", " TrkOff", " FmtGapReq", "",
+};
+
+char *SlowMedFast[] = {"slow", "medium", "fast"};
+char *BuffType[] = {"?", "1Sect", "DualPort", "DualPortCache"};
+
+#define YN(b) (((b)==0)?"no":"yes")
+
+static void rawstring (char *prefix, char *s, int n)
+{
+ printk(prefix);
+ if (*s) {
+ int i;
+ for (i=0; i < n && s[i^1] == ' '; ++i); /* strip blanks */
+ for (; i < n && s[i^1]; ++i)
+ if (s[i^1] != ' ' || ((i+1) < n && s[(i+1)^1] != ' '))
+ printk("%c",s[i^1]);
+ }
+}
+
+static void dmpstr (char *prefix, unsigned int i, char *s[], unsigned int maxi)
+{
+ printk(prefix);
+ printk( (i > maxi) ? "?" : s[i] );
+}
+
+static void dump_identity (unsigned int dev, unsigned short ib[])
+{
+ int i;
+ char dashes[] = "\n+-------------------------------------------------------------------+\n";
+ printk (dashes);
+ printk ("hd%c: Drive Identification Info:\n", dev+'a');
+ rawstring (" Model=",(char *)&ib[27],40);
+ rawstring (", FwRev=",(char *)&ib[23],8);
+ rawstring (", SerialNo=",(char *)&ib[10],20);
+ printk ("\n Config={");
+ for (i=0; i<=15; i++) if (ib[0] & (1<<i)) printk (cfg_str[i]);
+ printk (" }\n");
+ printk (" Default c/h/s=%d/%d/%d, TrkSize=%d, SectSize=%d, ECCbytes=%d\n",
+ ib[1],ib[3],ib[6],ib[4],ib[5], ib[22]);
+ dmpstr (" BuffType=",ib[20],BuffType,3);
+ ib[47] &= 0xFF;
+ printk (", BuffSize=%dKB, MaxMultSect=%d\n", ib[21]/2, ib[47]);
+ printk (" Features: DblWordIO=%s, LBA=%s, DMA=%s",
+ YN(ib[48]&1),YN(ib[49]&0x20),YN(ib[49]&0x10));
+ dmpstr (", tPIO=",ib[51]>>8,SlowMedFast,2);
+ if (ib[49]&0x10 && (ib[53]&1)==0)
+ dmpstr (", tDMA=",ib[52]>>8,SlowMedFast,2);
+ printk ("\n (%s): Current c/h/s=%d/%d/%d, TotSect=%d",
+ (((ib[53]&1)==0)?"maybe":"valid"),
+ ib[54],ib[55],ib[56],*(int *)&ib[57]);
+ if (ib[49]&0x20)
+ printk (", LBAsect=%d", *(int *)&ib[60]);
+ printk ("\n (%s): CurMultSect=%d", ((ib[53]&1)==0)?"maybe":"valid",
+ (ib[59]&0x10)?ib[59]&0xFF:0);
+ if (ib[49]&0x10)
+ printk (", DMA-1w=%04X, DMA-mw=%04X", ib[62], ib[63]);
+ printk ("%s\n",dashes);
+}
+#endif /* VERBOSE_DRIVEID */
+
+static void identify_intr(void)
+{
+ unsigned short ib[64];
+ unsigned int dev = DEVICE_NR(CURRENT->dev);
+
+ if (inb_p(HD_STATUS)&(BUSY_STAT|ERR_STAT))
+ printk (" hd%c: multiple mode not supported\n", dev+'a');
+ else {
+ insw(HD_DATA,(char *)ib,64); /* get first 128 ID bytes */
+ sti();
+#if VERBOSE_DRIVEID
+ dump_identity(dev, ib);
+#endif /* VERBOSE_DRIVEID */
+ if (ib[27]) {
+ int i;
+ for (i=27; i<= 46; i++)
+ ib[i] = (ib[i]>>8) | (ib[i]<<8);
+ printk (" hd%c: %-.40s (%dMB IDE w/%dKB Cache)\n",
+ dev+'a', (char *)&ib[27], ib[1]*ib[3]*ib[6] / 2048, ib[21]>>1);
+ }
+ insw(HD_DATA,(char *)ib,64); /* flush remaining 384 ID bytes */
+ insw(HD_DATA,(char *)ib,64);
+ cli();
+ insw(HD_DATA,(char *)ib,64);
+ }
+ do_hd_request();
+ return;
+}
+
--
mlord@bnr.ca Mark Lord BNR Ottawa,Canada 613-763-7482
------------------------------
From: bryan@pedro.phys.Virginia.EDU (bryan wright)
Subject: Xterm problem w/ 1.0
Date: Tue, 22 Mar 1994 18:29:19 GMT
Hi Folks,
This morning, I tried upgrading from 0.99pl15a to 1.0. Everything
seemed to work fine, except that I could no longer re-define keys in an xterm.
I have the following lines in my .Xdefaults file:
*VT100.Translations: #override <Key>F11: string("\033OP") \n \
<Key>KP_Divide: string("\033OQ") \n\
<Key>KP_Multiply: string("\033OR") \n\
<Key>KP_Subtract: string("\033OS") \n\
<Key>KP_Add: string("\033Ol") \n\
<Key>KP_7: string("\033Ow") \n\
<Key>KP_8: string("\033Ox") \n\
<Key>KP_9: string("\033Oy") \n\
<Key>KP_4: string("\033Ot") \n\
<Key>KP_5: string("\033Ou") \n\
<Key>KP_6: string("\033Ov") \n\
<Key>KP_1: string("\033Oq") \n\
<Key>KP_2: string("\033Or") \n\
<Key>KP_3: string("\033Os") \n\
<Key>KP_0: string("\033Op") \n\
<Key>KP_Decimal: string("\033On") \n\
<Key>KP_Enter: string("\033OM") \n
These generate the standard VT200 keypad escape sequences. This works fine
under 0.99pl15a and earlier, but fails under 1.0. The keypad keys under
1.0 seem to be "hard-wired" to generate a different set of escape sequences,
and xterm doesn't want to re-define them based on the resources in my
.Xdefaults. (I'm running Xfree 2.0, by the way.) For the time being, I've
gone back to 0.99pl15a, but I'd like to be able to use the latest version
of the kernel. Does anyone have any suggestions?
Thanks,
Bryan
--
===============================================================================
Bryan Wright |"If you take cranberries and stew them like
Physics Department | applesauce, they taste much more like prunes
University of Virginia | than rhubarb does." -- Groucho
Charlottesville, VA 22901 |
(804) 924-6814 | bryan@sphinx.phys.virginia.edu
===============================================================================
------------------------------
From: ptomblin@gandalf.ca (Paul Tomblin)
Subject: tcpdump: why is the -p flag reversed in meaning?
Date: 23 Mar 1994 11:07:05 -0500
I can't find anything about who ported tcpdump to linux, but I was wondering
why whoever did it REVERSED the meaning of the -p flag. If you look at
pcap-pf.c or pcap-snit.c, they both say:
if (pflag == 0)
<something flags> |= <something>PROMISC;
and in pcap-linux, it says:
if (pflag)
ifr.ifr_flags |= IFF_PROMISC;
I found this out quite by accident, and ftped the source yesterday to verify.
--
Paul Tomblin, Head - Automation Design Group.
Gandalf Canada Limited
This is not an official statement of Gandalf, or of Vicki Robinson.
"Hello, this is Linus Torvalds, and I pronounce Linux as Linux"
------------------------------
From: pjk@cyphyn.radnet.com (Pete Keyes)
Subject: Re: Printer Problems -- ANSWERS
Date: Wed, 23 Mar 94 04:03:22 GMT
Ken Kopilevich (kirill@crl.com) wrote:
:
:: tsx-11.mit.edu
^^^^^^^^^^^^^^^
Minor typo, tsx-11.mit.edu
:
sunsite.unc.edu
: ftp.funic.fi
^^^^^^^^^^^^
Minor typo, ftp.funet.fi
Pete
:
: Good Luck !
[much other relevant stuff deleted]
:
: Steve
:
------------------------------
Date: 23 Mar 1994 23:13:00 +0100
From: k.dittmann@anarch.ping.de (Kai Dittmann)
Subject: Afserver for Transputer under Linux ???
Hello...
i search for a port of the AlienFile-Server (AFServer) for a single T805
Board and a little TRAM-Network under Linux.
Does anyone know where i find them ??
I want use this thing to run my port of POV-Ray under Linux on a single
T805 Transputer...
Or, does anyone know how i find another port of POV for Transi ?
I have a little Transputernetwork with one T805 and 3*T425 and i want to
get all my Chips to work, because, this nettwerk runs currently without
any usefull solution or software and takes at this moment only very much
dust and energy...
kai dittmann
## CrossPoint v2.93 ##
------------------------------
From: jvoosten@compiler.tdcnet.nl (J.S. van Oosten)
Subject: Re: Proposal - Coordinating bug fixes with enhancements.
Date: Wed, 23 Mar 1994 01:48:20 GMT
Harvey J. Stein (hjstein@sunset.huji.ac.il) wrote:
: The way I see it, there are two general classes of changes that are
: made, namely bug fixes & enhancements.
I don't see it as strict: a lot of time short enhancements are included,
often a few lines of code that run faster or better as it should be, but
you can also see them as fixes then.
And in most cases, enhancements are shipped together with bugsfixes in a
single patch, and otherwise your coherency with the "real" sources would
break down very soon.
: My idea is to use a version number scheme that basically marks where
: the enhancements occur. It wouldn't be so different than the current
: method of numbered & lettered patch levels, except that there would be
: meaning in when the numbers & letters change.
: We could keep track of enhancements versus bug fixes by having
: versions consisting of four numbers (like internet addresses). We'd
: have Linux Version a.b.c.d, where c & d would be left out when they're
: zero. The meaning would be as in the following example:
: Version Status
: 1.0 Major release (only bug fixes).
: 1.0.0.1 Enhancement added.
: 1.0.0.2 Bug fix.
: 1.0.0.3 Bug fix.
: 1.0.0.4 Bug fix.
: 1.0.1 Last minor release before new enhancement (could be the same
: as version 1.0.0.4).
: 1.0.1.1 Enhancement added.
: 1.0.1.2 Bug fix.
: 1.0.1.3 Bug fix.
: 1.0.1.4 Bug fix.
: 1.0.1.5 Bug fix.
: 1.0.2 Minor release, only bug fixes, could be same as 1.0.1.5
: .
: .
: .
: 1.1 Major release.
Needlessly complex. Heck, if I save those patches on MS-DOS floppy I want to
spend a few letters on the word 'kernel' or 'linux' or something like that,
not a big row of numbers !
: Maybe pl<number> would be a minor release,
: just including bug fixes, pl<number><letter> would represent an
: enhancement when <letter> is a-l & bug fixes only from m-z, so that
: pl<n+1> is the same as pl<n><letter>, where <letter> is the last
: kernel in the pl<n> series, after bug fixes have been going in for
: afew lettered releases.
Excuse my sarcasm, but how are you going to explain to a relative new person
in Linux that pl103f could actually be newer than pl103q ??
: Or, we could use even and odd. Even numbered patch levels could be
: the kernels where enhancements go, and odd numbered patch levels could
: be bug fix only kernels. I think I like this last alternative the best.
Hmm, and get questions like: "I've seen pl103a, b, c & e, but where's 'd' ?"
: If people want to make this even stronger, they could even do as was
: done with version 1.0, namely having well defined times where
: enhancements are allowed in.
Now there's a point here. Since we're now (hopefully) released from the
'taming' as we were slowing growing to 1.00 with 0.99.14abcd.. 0.99.15abcd..
because we were running out of version numbers :-), we could now do this:
- New features in linux Like new drivers, code for advanced things like rpc,
and other stuff we come up with, are held back to a new major release,
that increases the version number by 1 (so the next major would be
linux 2.0)
- fixes etc. increase the version by a hundreth, so we get linux 1.01, 1.02,
1.03 and so on.
- The last fix _before_ a new major release gets number x.99, to indicate
that no newer fixes are expected for this release level. This would
be a stable, thoroughly debugged version you could use on the machines
at work, for example. The version (x+1).00, .01 .02 .. will be used
as the next development platform.
My .02
J. v. O.
--
Sometimes I wonder if this whole universe isn't anything more than a
simulation on a BIG computer. And they just might press Ctrl-C any time
now...
--
My PGP public key [version 2.3] (you know when, why and how...) :
mQCNAi1lYqsAAAEEAMCgUKS7DxyGF8D7QIGYXxRuh2n9Q2+5gIrrb1n9iOl4Xlgo
cO8Y3DE71J5K6WhlpEGDqXZIwY/Xx8mxq80ZHJ3n0pHOUxOQGdxxMT1mrKotjE4Y
wmGqnQhMhpcCKgT/5+5xhuMEluyGQqjyud3PCDogJCC/Sia7eO9+56e/13btAAUR
tC1KLlMuIHZhbiBPb3N0ZW4gPGp2b29zdGVuQGNvbXBpbGVyLnRkY25ldC5ubD4=
=3brb
------------------------------
From: jvi@uwasa.fi (-J.P.A.Vierinen-)
Crossposted-To: comp.os.linux,comp.os.linux.admin,comp.os.linux.help,comp.os.linux.misc
Subject: Re: GOD SPEAKS ON LINUX!
Date: 24 Mar 1994 13:36:00 GMT
Carlos Myers (myers_c@ab.wvnet.edu) wrote:
: In article <24FEB199429594568@up.there.above>, God@Up.There.Above (God) writes:
: > THIS IS THE VOICE OF THE LORD!
-Stuff Deleted-
Hahahahahah...Here we have one looser again!
By the way, do you know what CapsLock mean? :-)
-JuHa
*-------------------* **** *---------------------------*
* - M U L T I M E D I A For Mac & PC & Amiga *
* - U N I X & Linux OS For PC (386&486) *
* *
* Juha P.A. Vierinen - (jvi@chyde.uwasa.fi) *
* (jvi@freeport.uwasa.fi) *
*------------------------------------------------------*
------------------------------
From: y93chrwe@odalix.ida.liu.se (Christer Weinigel)
Subject: Re: <stddef.h> in libc-4.5.21?
Date: 22 Mar 94 05:13:48 GMT
toman@darkwing.uoregon.edu (Joseph Toman) writes:
>Hi, I am trying to compile various source code packages for "Lee-noocks" :)
>and I don't seem to have the ANSI C standard include file <stddef.h>. It is
>neither in Slackware 1.1.2 nor in libc-4.5.21 on tsx-11. Where can I find it?
When I got this error, I noticed that gcc searches for include files in
/usr/local/lib/gcc-include. This directory did not exist on my machine; I
guess this is a problem with Slackware 1.1.2. Well, anyway this solved the
problem for me. The line for cpp fixed some other problems I've had.
ln -s /usr/lib/gcc-lib/i486-linux/2.5.8/include /usr/local/lib/gcc-include
ln -s /usr/lib/gcc-lib/i486-linux/2.5.8/cpp /lib/cpp
/Christer Weingel
------------------------------
From: tgie@sun2 (Timo Giesselmann)
Subject: Re: Interrupts??
Reply-To: tgie@tet.uni-hannover.de
Date: Thu, 24 Mar 1994 22:34:16 GMT
Pieter.Verhaeghe (pive@uia.ac.be) wrote:
: Probably a confusing subject, but let me explain the problem:
: I have a notebook, which starts beeping and flashing (a led) whenever
: the batteries are low. This didn't work under Linux, so I started to
: disassemble the BIOS. I'm rather convinced that everything happens
: in the DOS interrupt 8 which does the following
: jump to the int 8 location
: [...]
: read a certain port number and put the result in AL
: according to the value of AL beep/flash or do nothing
: [...]
: iret
: My question is: how can I implement this behaviour in Linux?
: (or better: does there exists a skeleton for implementing this?)
: Thanks
: Pieter
With DOS (resp. the BIOS), interrupt 8 is invoked 18.2 times a second
by the hardware.
You should write a user mode driver. It is described in the Kernel
Hackers Guide very well. A user mode driver is just a normal process
running under Linux that is allowed to access the ports. You may write
an infinite loop that sleeps e.g. for 10 seconds and then checks the
port and invokes any action when battery is empty, then sleeps again.
So you don't need to patch the kernel.
This Watchdog process may be invoked by the system startup rc file.
--
Timo Giesselmann
tel.: +511/797098
e-mail: tgie@tet.uni-hannover.de
------------------------------
From: newt@eng.umd.edu (Daniel S. Ridge)
Subject: PTY bug?
Date: 24 Mar 1994 17:52:02 GMT
Is there a bug in the kernal pty handling that would keep me from running
SLIP over a pty line?
I have been unable to do this. The symptom is that if I start a SLIP
session on a pty line, I am unable to connect to any of the ports on the
server machine (not just from my machine, but from any machine. I can't even
sit down at the console of the server and telnet loopback. It prints "login:"
and then immediatly closes the connection.
Has anyone else had this problem? Will I not be able to SLIP over a pty line?
Thanks,
Dan Ridge
(newt@eng.umd.edu)
------------------------------
From: plocher@attaboy (John Plocher)
Subject: Re: Proposal - Coordinating bug fixes with enhancements.
Date: 24 Mar 1994 00:48:39 GMT
: - New features in linux Like new drivers, code for advanced things like rpc,
: and other stuff we come up with, are held back to a new major release,
From a systems view, there are two kinds of changes:
1) Major ones that change existing interfaces
2) minor ones that only change implementations of an existing
interface.
Tying into this discussion, as long as the device driver <==> kernel
interface was unchanged, I could use any driver version with any kernel
version.
The Golden Rule would be that you can *never* delete functionality from
an interface without potentially breaking ALL existing code. Thus, a
well defined interface can be more important than several quick-hack
generations of implementations.
In the distributed development world that Linux is evolving in, the
definition of strong interfaces (POSIX, COSE/1170, STREAMS/sockets...)
is a powerful tool. We should strive to use it...
Just my opinions...
-John
------------------------------
From: frankg@halcyon.halcyon.com (Frank Gleason)
Subject: Re: LINUX port to a transputer system
Date: 23 Mar 1994 02:51:35 GMT
Antoni.Baranski@si.hhs.nl (Baranski, A.S.) writes:
>Hi World,
> I am a student at the Haagse HogeSchool Sector Informatica in the Hague, Holland.
>During my summer holliday I am planning on making a port of LINUX onto a T800
>transputer subsystem which plugs into my PC.
>Thanx
>------------------------------------------------|
>Baranski, A. S. | Haagse HogeSchool |
>E-Mail: | Sector Informatica |
>Antoni.Baranski@si.hhs.nl | Student Software Engineering |
>------------------------------------------------|
You may wish to look at the Minix port available on
ftp.inmos.co.uk:software/os
The source has not been released yet but you may be able
to get it if you ask. I would be interested if you get it.
Minix uses the isever and does run under Linux.
frankg@halcyon.com
------------------------------
** 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
******************************