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

add directory docs

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:23:35 -05:00
parent b50063d9b3
commit 9912ec445d
12689 changed files with 3135349 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

599
docs/mail-archive/linux-devel/Volume1/digest5XX/digest564 Normal file
View File

@@ -0,0 +1,599 @@
Subject: Linux-Development Digest #564
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: Sat, 19 Mar 94 11:13:10 EST
Linux-Development Digest #564, Volume #1 Sat, 19 Mar 94 11:13:10 EST
Contents:
Re: slip + ftp question (lilo)
Re: slip + ftp question (DavidM9555)
program to watch IRQs (dave archer)
Re: SIGIO with Non-Blocking sockets? (Rajat Datta)
Automatic module loader/unloader (Erik Troan)
Re: blank_screen patch for Laptops (Questions) (James H. Cloos Jr.)
Re: 486DLC support anyone? (Jonathan H. Abrams)
identd and number of TCP sockets (Juha Virtanen)
[GE_|J]COOL port (Bob Tanner)
Adpatec 2842 SCSI Driver .. (Wolfgang Jung)
Re: Starting a Linux Bibliography (Phil Packer)
----------------------------------------------------------------------------
From: lilo@slip-11-12.ots.utexas.edu (lilo)
Subject: Re: slip + ftp question
Date: 19 Mar 1994 04:51:23 GMT
On 19 Mar 1994 01:36:04 GMT, Dan Tran (dant@minerva.rolm.com) wrote:
> Do I need separate implementations of ftp to transfer data between from
> A to C, and B to C. Due to different hardwares.
No: ftp never sees the hardware. It operates at an application level, well
above such things. You simply need to make sure that your route commands
are set up so that network addresses that need to be accessed by C through A
are routed through that network connection, and addresses that need to be
accessed by C through B are routed through *their* appropriate connection.
lilo
------------------------------
From: davidm9555@aol.com (DavidM9555)
Subject: Re: slip + ftp question
Date: 19 Mar 1994 00:03:01 -0500
There answer is a succint no. FTP is a standard protocol and therefore
any FTP client should be able to talk to any FTP server. So, A could talk
to B with FTP no matter who ran which implementation on which machine
on either end.
Later,
David S. Miller
davidm9555@aol.com
------------------------------
From: dmarcher@acsu.buffalo.edu (dave archer)
Subject: program to watch IRQs
Date: Sat, 19 Mar 1994 01:10:57 GMT
does anyone have a program to watch IRQs? is it even
possible to do such a thing at the user level?
(i suspect i've got something generating hardware
interrupts that shouldn't be and want to see if i can
"prove" it.)
thanks,
Dave
------------------------------
From: rajat@austin.ibm.com (Rajat Datta)
Subject: Re: SIGIO with Non-Blocking sockets?
Date: Fri, 18 Mar 1994 17:16:51 GMT
Reply-To: rajat@austin.ibm.com
In article <KWH.94Mar18003059@markov.cs.brown.edu>,
Kwun Han <kwh@cs.brown.edu> wrote:
>Hi Linux hackers out there,
>
> I am writing a program which requires non-blocking sockets in
>Linux, however, I am not getting the right behaviour. What I did was,
>I first register the signal handler for SIGIO, then I established the
>socket connection, then I used the ioctl -> FIONBIO, FIOSETOWN
>FIOASYNC to make sure that the socket will signal my process when it
>gets something.
>
>Here is where the problem is:
>
>When I send some stuff from the other side of the socket, the stuff
>get read if I do an infinite loop polling the socket, but I am not
>getting signaled at all.
>
>I tested the code in both SunOS and Solaris, they works as
>expected. So I am sure this has something to do with Linux, am I
>missing something here??
>
>Thanks!
>
>Kwun
I believe Linux does not implement delivering the SIGIO signal on file
descriptors (yet?). I found two obvious ways to get around the
problem. One is to ask the sender to also send a SIGxxxx signal after
the write to the socket. The other is to have the receiver fork off a
process which does a select on the socket and passes up a SIGxxxx
signal to the parent when it detects something is on the way.
--
Rajat Datta opinions are my own and not my employer's
------------------------------
From: ewt@sunSITE.unc.edu (Erik Troan)
Subject: Automatic module loader/unloader
Date: 19 Mar 1994 04:06:32 GMT
A while ago some people on this newsgroup were asking about the
feasibility of having modules loaded automatically when something
tried to use them.
I though this was a neat idea, so I wrote something to load modules
that implement character devices when something tries to open
/dev/whatever and unload the device once /dev/whatever has been released.
My code is a module and a daemon - the only kernel change that might
is needed is adding _get_chrfops to ksyms.S.
I've tried this code on the drv_hello and joystick drivers. I'd like
someone to try it with ftape and see if it works.
Anyway, the code and some basic docs are available on sunsite.unc.edu
at /pub/Linux/ALPHA/moddev/moddev-0.1.tar.gz.
Comments here or by email are most welcome.
Erik
--
===========================================================================
"I'm not like that -- except when I am" ewt@sunsite.unc.edu = Erik Troan
sasewt@unx.sas.com
- Nora from "Pump up the Volume"
------------------------------
From: James.Cloos@Rahul.NET (James H. Cloos Jr.)
Subject: Re: blank_screen patch for Laptops (Questions)
Date: Sat, 19 Mar 1994 11:09:30 GMT
I was waiting on this until I finished it, but I thought I should
followup now anyway.
I had previously hacked version 99.14 to turn off my backlight at
timeout, and leave it on when graphics mode was activated.
I decided to do a cleaner mod for 1.0.
The following patch to drivers/char/console.c and include/linux/tty.h
adds the beginings of support for a user space daemon that can
function as a general screen saver--whether than means controllong the
backlight, or wastings cpu time on a fireworks display ;-) or
whatever.
What I need to do is add an ioclt to register the pid of said daemon
so that the kernel can signal it.
I also want to request comments on the signals to send to the daemon,
and whether some heuristic is needed to confirm the pid still existst.
I expect the daemon to set up its signal handlers, call the as-yet-
to-be-added ioclt to register itself, and wait for signals. The
handler for SIGTERM &c should call the ioclt to unregister itself.
Comments?
========================================
diff -u linux/drivers/char/console.c_1.0 linux/drivers/char/console.c
--- linux/drivers/char/console.c_1.0 Wed Feb 23 01:52:24 1994
+++ linux/drivers/char/console.c Thu Mar 17 04:29:57 1994
@@ -14,6 +14,8 @@
* 'void update_screen(int new_console)'
* 'void blank_screen(void)'
* 'void unblank_screen(void)'
+ * 'void user_blank_screen(void)'
+ * 'void user_unblank_screen(void)'
*
* 'int con_get_font(char *)'
* 'int con_set_font(char *)'
@@ -35,6 +37,9 @@
* Code to check for different video-cards mostly by Galen Hunt,
* <g-hunt@ee.utah.edu>
*
+ * user_{un}?blank_screen() Copyright 1994 by James H. Cloos, Jr.
+ * <James.Cloos@Rahul.NET>
+ *
*/
#define CAN_LOAD_EGA_FONTS /* undefine if the user must not do this */
@@ -148,6 +153,7 @@
unsigned short *vc_scrbuf[NR_CONSOLES];
static unsigned short * vc_scrmembuf;
static int console_blanked = 0;
+static int user_blank_pid = 0;
#define origin (vc_cons[currcons].vc_origin)
#define scr_end (vc_cons[currcons].vc_scr_end)
@@ -1402,7 +1408,7 @@
video_page = ORIG_VIDEO_PAGE;
screen_size = (video_num_lines * video_size_row);
kmem_start += NR_CONSOLES * screen_size;
- timer_table[BLANK_TIMER].fn = blank_screen;
+ timer_table[BLANK_TIMER].fn = user_blank_screen;
timer_table[BLANK_TIMER].expires = 0;
if (blankinterval) {
timer_table[BLANK_TIMER].expires = jiffies+blankinterval;
@@ -1550,18 +1556,31 @@
{
if (console_blanked)
return;
- timer_table[BLANK_TIMER].fn = unblank_screen;
+ timer_table[BLANK_TIMER].fn = user_unblank_screen;
get_scrmem(fg_console);
hide_cursor();
console_blanked = 1;
memsetw((void *)video_mem_base, 0x0020, video_mem_term-video_mem_base );
}
+void user_blank_screen(void)
+{
+ if (console_blanked)
+ return;
+ blank_screen();
+#if 0
+/* we want to send SIGUSR1 to the registered process, if any. */
+/* perhaps SIGCONT would be better? */
+ if (user_blank_pid)
+ (void) kill_proc(user_blank_pid,SIGUSR1,1);
+#endif
+}
+
void unblank_screen(void)
{
if (!console_blanked)
return;
- timer_table[BLANK_TIMER].fn = blank_screen;
+ timer_table[BLANK_TIMER].fn = user_blank_screen;
if (blankinterval) {
timer_table[BLANK_TIMER].expires = jiffies + blankinterval;
timer_active |= 1<<BLANK_TIMER;
@@ -1572,6 +1591,19 @@
set_cursor(fg_console);
}
+void user_unblank_screen(void)
+{
+ if (!console_blanked)
+ return;
+ unblank_screen();
+#if 0
+/* we want to send SIGUSR2 to the registered process, if any. */
+/* perhaps SIGSTOP would be better? */
+ if (user_blank_pid)
+ (void) kill_proc(user_blank_pid,SIGUSR2,1);
+#endif
+}
+
void update_screen(int new_console)
{
static int lock = 0;
@@ -1671,7 +1703,7 @@
int i, ps, pe;
char *off = (char *)origin - hwscroll_offset;
- unblank_screen();
+ user_unblank_screen();
args = (unsigned short *)(arg + 1);
xs = get_fs_word(args++) - 1;
ys = get_fs_word(args++) - 1;
@@ -1805,7 +1837,7 @@
if (! *bp)
return 0;
- unblank_screen();
+ user_unblank_screen();
while (*bp) {
put_tty_queue(*bp, &tty->read_q);
bp++;
diff finished at Sat Mar 19 05:56:30
diff -u linux/include/linux/tty.h-1.0 linux/include/linux/tty.h
--- linux/include/linux/tty.h-1.0 Fri Feb 18 04:08:41 1994
+++ linux/include/linux/tty.h Thu Mar 17 04:30:52 1994
@@ -438,7 +438,9 @@
extern int con_open(struct tty_struct * tty, struct file * filp);
extern void update_screen(int new_console);
extern void blank_screen(void);
+extern void user_blank_screen(void);
extern void unblank_screen(void);
+extern void user_unblank_screen(void);
/* vt.c */
diff finished at Sat Mar 19 05:58:01
=====================================
--
James H. Cloos, Jr. include <std/qotd>
James.Cloos@Rahul.NET include <std/disclaimers.h>
(cloos@io.com) Snail: POBox 1111, Amherst, NY 14226-1111
Finger for pgp pub key. Phone: +1 716 673-1250 (machine now; fax eventually)
------------------------------
From: abrams@maccs.mcmaster.ca (Jonathan H. Abrams)
Subject: Re: 486DLC support anyone?
Date: Sat, 19 Mar 1994 02:02:40 GMT
In article <Mar18.025419.15746@acs.ucalgary.ca>,
Superuser <root@fusion.cuc.ab.ca> wrote:
>cjthomas@metronet.com (Chris Thomas) writes:
>> I just popped a TI486DLC cpu into my system only to discover that there is a
>> DOS program that enables the internal cache on the chip. It works great
>> for DOS, but linux is still kind of slow.
>> Has anyone tried to add DLC support to the kernel? For that matter, does
>> anyone know how to enable the internal cache of the CPU?
>
>Grab CxPatch.tar.gz from sunsite.unc.edu in /pub/Linux/kernel/misc-patches
>(or thereabouts).
>
Is this neccessary if I have set the internal cache enabled in the AMi
bios setting?
Jonathan H. Abrams McMaster University
abrams@acm.org Hamilton, Ontario, Canada
------------------------------
From: Juha.Virtanen@hut.fi (Juha Virtanen)
Subject: identd and number of TCP sockets
Date: 19 Mar 94 12:42:43 GMT
Reply-To: jiivee@hut.fi
I installed yesterday in.identd from pidentd-2.2beta.4 package.
It compiled fine and seems to work also.
However, every time in.identd is executed kernel complains about
too many TCP sockets for netinfo. That's not very nice because
those messages are written to syslog every two minutes or so (and
files are growing fast). I have noticed that executing command
"netstat" also causes those "oops, too many TCP sockets for
netinfo messages".
Questions: What to do to get rid of those messages? I looked into
kernel sources and found that number of sockets is defined in
.../net/inet/sock.h to be 64, but I'm not out of sockets...
.../net/inet/proc.c around line 97:
/* Is place in buffer too rare? then abort. */
if (pos > buffer+PAGE_SIZE-80) {
printk("oops, too many %s sockets for netinfo.\n",
pro->name);
return(strlen(buffer));
These lines are causing annoying messages. Why buffer is only one
page, not more or why netinfo buffer's size isn't determined
during compilation time from the value of SOCK_ARRAY_SIZE and
allocated always appropriately? Now get__netinfo can only return
info about max 51 sockets. Or is this behaviour feature because
it is documented in comments ;-) ?
---sample from kernel messages:
Mar 19 13:37:39 iguana kernel: oops, too many TCP sockets for netinfo.
Mar 19 13:37:39 iguana last message repeated 24 times
Mar 19 13:39:41 iguana last message repeated 25 times
Mar 19 13:41:42 iguana kernel: oops, too many TCP sockets for netinfo.
Mar 19 13:43:43 iguana kernel: oops, too many TCP sockets for netinfo.
Mar 19 13:43:43 iguana kernel: oops, too many TCP sockets for netinfo.
Mar 19 13:45:45 iguana last message repeated 2 times
Mar 19 13:47:46 iguana kernel: oops, too many TCP sockets for netinfo.
Mar 19 13:48:54 iguana last message repeated 2 times
Mar 19 13:49:47 iguana last message repeated 6 times
Mar 19 13:51:47 iguana kernel: oops, too many TCP sockets for netinfo.
Mar 19 13:51:47 iguana last message repeated 2 times
Mar 19 13:53:48 iguana last message repeated 3 times
Mar 19 13:55:49 iguana kernel: oops, too many TCP sockets for netinfo.
Mar 19 13:55:49 iguana last message repeated 2 times
My environment: Linux 1.0 with acct-1.1 patches, lib[cm].so.4.5.21,
gcc-2.5.8 on i486/33MHz/64KB with 16MB RAM and SCSI disk.
Regards,
Juha
--
THE CHEMIST'S RULE: Never take more than three data points. There will always
be some kind of graph paper on which they fall in a straight line.
THE CHEMIST'S RULE, FIRST COROLLARY: If you have only one kind of graph paper,
never take more than two data points.
------------------------------
From: tanner@gnume.emphasys.com (Bob Tanner)
Subject: [GE_|J]COOL port
Date: 17 Mar 1994 18:13:54 GMT
I am posting here do to that fact that is could effect certain people who
develop on linux under g++.
Has anyone ported GE_COOL, JCOOL or plain COOL to linux?
COOL is the base objects for a very nice container classes. Before I jump in
and hack at it, I would like to see if anyone else has gone thru the effort.
------------------------------
From: wong@cs.tu-berlin.de (Wolfgang Jung)
Subject: Adpatec 2842 SCSI Driver ..
Date: 19 Mar 1994 15:49:29 GMT
Hi
==
I would like to know when there will be a SCSI Driver for the
2842 (if at all )
I read a message of an upcoming Driver for the 2842 about 3 1/2 Month
ago.. So I would llike to know how far the development for that
Adapter went ..
Thanks
Wolfgang
PS: I would like email.
------------------------------
Crossposted-To: comp.os.linux.admin,comp.os.linux.misc
From: pep@wicked.demon.co.uk (Phil Packer)
Subject: Re: Starting a Linux Bibliography
Date: Fri, 18 Mar 1994 13:40:23 +0000
In article <2mbfit$15l@darkstar.UCSC.EDU> haynes@cats.ucsc.edu (James H. Haynes) writes:
>
> I'm starting a bibliography of publications likely to be helpful in the
> Linux community. Please send me information about things you think should
> be included. The following is what I have for a starter. When there's more
> I will probably turn it into a HOWTO file and post it periodically.
> Please include your comments on the items so it become an annotated
> bibliography.
>
>
> I. Hardware
>
> Upgrading and Repairing PCs; Mueller, Scott; Que Corp.; ISBN 0-88022-856-3;
> 1298pp; 2nd ed. 1992; $34.95 (USA). This is a book I bought when I was
> struggling with an AT-clone. It is best on XTs and ATs and IBM PS/2s.
> Still, there is a wealth of information common to all models. EISA and
> VESA are mentioned only in the glossary.
>
> 80386 Hardware Reference Manual; Intel Corp.; ISBN 1-55512-024-5; ?pp.;
> 1986; $?. Pin connections, timing, waveforms, block diagrams, voltages,
> all that kind of stuff.
>
>
> II. Processor architecture and programming
>
> 80386 Programmer's Reference Manual; Intel Corp.; ISBN 1-55512-022-9;
> ?pp.; 1986; $?. Part I. Applications Programming, data types, memory
> model, instruction set. Part II. Systems Programming, architecture,
> memory management, protection, multitasking, I/O, exceptions and
> interrupts, initialization, coprocessing and multiprocessing. Part III.
> Compatibility (with earlier x86 machines). Part IV. Instruction Set.
>
> 80386 System Software Writer's Guide; Intel Corp.; ISBN 1-55512-023-7;
> ?pp.; 1987; $?. This explains the 386 features for operating system
> writers. It includes a chapter on Unix implementation. A lot of the
> 80386 architecture seems to have been designed with Multics in mind;
> the features are not used by DOS or by Unix.
>
> Programming the 80386; Crawford, John H., and Gelsinger, Patrick P.;
> Sybex; ISBN 0-89588-381-3; 774pp.; $26.95 (USA). This is the book the
> Jolitzes used when they ported BSD to the 386 architecture.
>
> Pentium Processor User's Manual: Volume 3, Architecture and Programming
> Manual; Intel Corp.; ISBN 1-55512-195-0; ?pp.; 1993; $?. Pretty much
> the Pentium version of the 80386 Programmer's manual listed above.
>
>
> III. Unix Kernel Implementation
>
> The Design of the Unix Operating System; Bach, Maurice J.; Prentice-
> Hall; ISBN 0-13-201799-7; 470pp.; $60 (USA). The book that got Linus
> started.
>
> The Design and Implementation of the 4.3BSD Unix Operating System;
> Leffler, Samuel J., McKusick, Marshall Kirk, Karels, Michael J., and
> Quarterman, John S.; Addison-Wesley; ISBN 0-201-06196-1; 471 pp.;
> 1989, 1990; $44.95 (USA). So, it's not about Linux, but can you
> afford to ignore it?
>
> Kernel Hacker's Guide; Linux Documentation Project; FTP sites;
> 1994.
>
> IV. System Calls
>
> The Posix.1 Standard: A Programmer's Guide; Zlotnick, Fred; Benjamin/
> Cummings; ISBN 0-8053-9605-5; 379pp.; 1991; $35.95 (USA). When I
> complained about the lack of Section 2 man pages in Linux, somebody
> told me just to get a POSIX book, because that's what Linux does.
> I like this book because I'm not a professional programmer and the
> author gives copious explanations and examples.
>
>
> V. Networking
>
> Unix Network Programming; Stevens. W. Richard; PTR Prentice Hall;
> ISBN 0-13-949876-1; 772 pp.; $54 (USA). Everything you might want to
> know about the subject, and some things you probably don't want to
> know (really, XNS!?).
>
> Networking Guide; Linux Documentation Project; FTP sites; 1993.
Internetworking With TCP/IP: Volume 1, 2nd edition; Principles,
Protocols, and Architecture; Comer. E. Douglas; Prentice Hall;
ISBN 0-13-474321-0; 23.95 UKP
One of those books that I am constantly referring to.
>
>
> VI. General (or hard-to-classify)
>
> Bell System Technical Journal, July-August 1978, Vol. 57, No. 6, part 2;
> AT&T; 416 pp. Many papers on Unix, including Ritchie & Thompson,
> "The UNIX Time Sharing System"; Thompson, "UNIX Implementation";
> Ritchie, "A Retrospective"; Bourne, "The UNIX Shell"...
>
> VII. System Installation
>
> Linux Installation and Getting Started; Linux Documentation Project;
> FTP sites; 175 pp.; 1994.
>
> VIII. System Administration
>
> Linux System Administrator's Guide; Linux Documentation Project;
> FTP sites; 1993.
> --
> haynes@cats.ucsc.edu
> haynes@cats.bitnet
>
> "Ya can talk all ya wanna, but it's dif'rent than it was!"
> "No it aint! But ya gotta know the territory!"
> Meredith Willson: "The Music Man"
>
Cheers,
Phil
| PERSCRIPTIO IN MANIBVS TABELLARIORVM EST (The cheque's in the post) |
+-----------------------------+-----------------------------------------------+
|Phil Packer [ G8MDA ] | pep@wicked.demon.co.uk (home) |
|165 Stourton Avenue Hanworth | pep@cix.compulink.co.uk (deprecated!) |
|Middlesex, England TW13 6LD | pp1071bh@bh.bbc.co.uk (RFC822@work) |
| +44 081 898 0101 | PP1071BH@BBC-BH [via NHUB] (MHS@work) |
| C=GB;ADMD=GOLD 400;PRMD=BBC;O=RADIO;S=PP1071BH (X.400@work) |
| wicked is not associated with any other demon dial-up site |
+-----------------------------------------------------------------------------+
------------------------------
** 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
******************************