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

573
mail-archive/linux-devel/Volume1/digest5XX/digest582 Normal file
View File

@@ -0,0 +1,573 @@
Subject: Linux-Development Digest #582
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: Sun, 27 Mar 94 06:13:09 EST
Linux-Development Digest #582, Volume #1 Sun, 27 Mar 94 06:13:09 EST
Contents:
Re: A truely non-debugging Kernel? (David Dyer-Bennet)
BOOTP support for DIP added (Charles Hedrick)
Async I/O (Frank Lofaro)
Magic of .. (Re: Amiga FileSystem, Anyone?) (Kari E. Hurtta)
Re: Proposal - Coordinating bug fixes with enhancements. (Linus Torvalds)
Re: program to watch IRQs (Phil Howard)
linux on macintosh? (Jaime C Mantel)
linux and macintosh (Jaime C Mantel)
----------------------------------------------------------------------------
From: ddb@terrabit.uucp (David Dyer-Bennet)
Subject: Re: A truely non-debugging Kernel?
Date: Sat, 26 Mar 1994 15:40:00 GMT
kevin@frobozz.sccsi.com (Kevin Brown) writes:
>In article <2mfk5o$jfu@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Torvalds) writes:
>> - I *do* assume the kernel is going to crash, and no, I don't
>> presonally like the idea of letting the user easily shut down some of
>> the sanity checks I write. Admittedly, they happen very seldom, and
>> they have a tendency to stay in even after I trust the code, but
>> you'd be surprised how many *hardware* bugs they've found.
>I would say, offhand, that it should be up to the user whether they run a
>safe kernel or not. After all, if their kernel dies on them and wreaks
>havoc, it's *their* fault that they compiled their kernel with sanity
>checks disabled, no? I would say that sanity checks turned on should
>definitely be the default, but not enforced.
I have nothing against letting, nay, encouraging, users to muck around
with the operating system, so long as they understand that they are
becoming test pilots by doing so.
*However*, most of us, myself included so far, haven't delved into the
Linux kernel very deeply. I'm in no position to make any sort of
reasoned decision about how to set any sort of debugging switches
provided. I *very much* want some clear direction from those working
in the kernel (who *I hope* :-) understand it better than I do) as to
how I should set any debug switches they have left around for normal
operation. What I get in the config file on 99.15 and 1.0 I can
understand and it seems obvious how I should set the debug option or
two that's there.
The distinction between "debugging code" and "self-defense code" is
entirely in the eye of the beholder. I consider Linus' eye's opinion
overwhelmingly more useful than my own at this point.
I'd be very unhappy if in some future release I got a switch that said
to me "I control some debug code. Maybe I'm not really necessary. Do
whatever you think is right." I'd either have to guess, or spend a
*lot* of time to learn enough to make a reasoned decision. I want
advice from the experts on that sort of issue.
--
David Dyer-Bennet, proprietor, The Terraboard 4242 Minnehaha Ave. S.
ddb@network.com, lynxds.mn.org!terrabit Minneapolis, MN 55406
Don't waste your time arguing about allocating blame; +1-612-721-8800
There'll be enough to go around. Fax +1-612-724-3314
------------------------------
From: hedrick@athos.rutgers.edu (Charles Hedrick)
Crossposted-To: ru.comp.dev
Subject: BOOTP support for DIP added
Date: 27 Mar 94 05:25:50 GMT
I've added bootp support to dip. This is useful for people who use
SLIP servers that assign them a different IP address each time. In
your dip script, use the command "bootp" right before enabling SLIP or
CSLIP. (You must use it after the modem is open and at the right
speed.) E.g.
dip -t
port tty65 ;use your actual tty name, probably ttys0 or ttys1
speed 19200 ;or whatever speed you're really using
get $mtu 192
bootp
mode CSLIP
Bootp will set locip and rmtip based on the bootp response from the
server. It will time out the request in 3 sec and try up to 3 times.
(These can be changed by specifying arguments to the bootp command,
e.g. "bootp 2 5" to try twice with a timeout of 5 sec.)
This version of dip (based on 3.3.7, from Linus' net-sources
subdirectory) is on athos.rutgers.edu, in /pub/linux. Included is
dip - executable
dip.diff-for-bootp - diffs to implement bootp
dip.8 - updated man page
I have dip do the bootp protocol itself. Thus I include pieces of IP,
UDP, and SLIP. It would be possible to enable SLIP and then use
kernel facilities to send and receive the packets. However routing
over a network for which you don't yet have IP addresses gets sort of
tricky, particularly if there may be other interfaces active. So it
seemed best to do bootp directly out the serial line, without
involving the kernel TCP/IP implementation. Note that the bootp will
always do SLIP. If you're using PPP this isn't going to work. (I
don't know enough about PPP to do an implementation of it.) It will
work with either SLIP or CSLIP, since there's no difference between
these for UDP packets.
I've updated the SLIP instructions on athos to suggest using this
feature.
------------------------------
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: Async I/O
Date: Sun, 27 Mar 94 05:41:42 GMT
I am in the process of implementing async I/O when I saw Ted Tso said
he was going to implement it too. Is that true?
I am using 1.0.4 witth Ted Tso' tty-patches (I patched them into
0.99.15h and upgraded the kernel doing manual patching where needed).
Anyway, this is what I have done so far:
I used (abused) the existing wake_up function so that the low level
drivers do not need to be messed with too much.
Added a f_owner field to the struct file.
Added SETOWN/GETOWN fcntl's.
Added an async operation to the struct file_operations and the line
discipline code for tty devices:
From struct file_operations:
void (*async) (struct inode *, struct file *, int);
For the line discipline the async function also takes a tty argument.
The int is a flag saying whether to turn async notification on or
off.
Added a fcntl to turn on/off async I/O on a descriptor.
Added a flag to the struct wait_queue that determines if
wake_up_interruptible should wake up the process or send a SIGIO.
Made a modified add_to_wait_queue (async_add_tto_wait_queue) that sets
the flag so wake_up_interruptible will send a SIGIO.
Added a tty_async call which adds a process to the wait queue using
async_add_to_wait_queue.
Problems remaining:
For this list, process A is the process turning on async I/O, process B
is the one set to receive signals (could be the same as A).
When A adds B to the wait queue, how can it later remove it?
When A or B dies, how to clean up?
If B dies and another process gets the same process slot, how to
avoid it getting signaled?
If A dies, how to turn off async I/O.
I am thinking I might have to add a pointer to a linked list of async
wait_queue entries to the task struct, but I'd REALLY rather not!
How the heck do I handle pgrps, etc properly? How can I tell a pgrp
"died"?
The way the TCP code handles SIGURG might help me, but the TCP code is
a bit hard for me to understand, and I don't know if it handles
everything right. (e.g. does it handle the process getting SIGURG's
dying correctly, or would a new process that got the same pid get
signals, assuming the kernel never tried to signal when their was no
process with that pid in use).
It is quite a while from being usable. It false triggers, turing off
async I/O or exiting the process turning it on crashes linux, etc. but
as proof of concept, the user program DOES get SIGIO's when I make
input available. I think I can work the bugs out with a little bit of work.
Here are the various functions and structs I added. I took them from a
huge file containing a lot of diffs (all my local patches including
much unrelated kernel hackery) and due to the urgency of the situation
(Ted Tso or someone supposedly starting work on async I/O, I want to
stay compatible and possibly help out) I want to get this post out
ASAP, so I don't have time to make a real diff yet. Its also missing
all the litttle changes here and there, like making initializations of
wait_queues {current, 0, NULL} instead of {currentt, NULL} but
everything needed to understand what is being done is hopefully
here. I am sorry about the mess, but I hope this gives people a clue
as to what I am doing:
+static void n_tty_async(struct tty_struct * tty, struct inode *
inode,
+ struct file * file, int on_off)
+{
+ struct wait_queue * wait;
+ wait = (struct wait_queue *) kmalloc(sizeof(struct
wait_queue), GFP_KERNEL);
+ wait->task=current;
+ wait->flags=1;
+ wait->next=NULL;
+ printk(KERN_DEBUG "n_tty_async: tty: %08x, inode %08x, file:
%08x, on_off: %d\n", tty, inode, file, on_off);
+ if (on_off) {
+ async_add_wait_queue(&tty->secondary.proc_list, wait);
+ async_add_wait_queue(&tty->write_q.proc_list, wait);
+ } else {
+ remove_wait_queue(&tty->secondary.proc_list, wait);
+ remove_wait_queue(&tty->write_q.proc_list, wait);
+ }
+}
+
struct tty_ldisc tty_ldisc_N_TTY = {
TTY_LDISC_MAGIC, /* magic */
0, /* num */
@@ -841,6 +859,7 @@
NULL, /* ioctl */
n_tty_set_termios, /* set_termios */
normal_select, /* select */
+ n_tty_async, /* async */
0, /* read_flush */
n_tty_receive_char, /* receive_char */
n_tty_receive_break, /* receive_break */
+static void tty_async(struct inode * inode, struct file * filp, int
on_off)
+{
+ struct tty_struct * tty;
+
+ tty = filp->private_data;
+ if (tty_paranoia_check(tty, inode->i_rdev, "tty_async"))
+ return;
+
+ if (tty->ldisc.async)
+ return (tty->ldisc.async)(tty, inode, filp, on_off);
+ return;
}
diff -r -u -N linux.unhacked/drivers/net/slip.c
linux/drivers/net/slip.c
--- linux.unhacked/drivers/net/slip.c Mon Mar 21 23:02:21 1994
+++ linux/drivers/net/slip.c Mon Mar 21 23:02:44 1994
@@ -1173,6 +1173,7 @@
sl_ldisc.ioctl = (int (*)(struct tty_struct *, struct file *,
unsigned int, unsigned long))
slip_ioctl;
sl_ldisc.select = NULL;
+ sl_ldisc.async = NULL;
sl_ldisc.read_flush = slip_recv;
if ((i = tty_register_ldisc(N_SLIP, &sl_ldisc)) != 0)
printk("ERROR: %d\n", i);
fs/fcntl.c:
@@ -92,6 +100,19 @@
return fcntl_setlk(fd, cmd, (struct flock *)
arg);
case F_SETLKW:
return fcntl_setlk(fd, cmd, (struct flock *)
arg);
+ case F_GETOWN:
+ return filp->f_owner;
+ case F_SETOWN:
+ /* XXX: could be less restrictive */
+ if (current->pgrp != -arg &&
+ current->pid != arg && !arg && !suser())
+ return(-EPERM);
+ filp->f_owner = (signed int) arg;
+ if (S_ISSOCK (filp->f_inode->i_mode))
+ {
+ return (sock_fcntl (filp, cmd, arg));
+ }
+ return 0;
default:
/* sockets need a few special fcntls. */
if (S_ISSOCK (filp->f_inode->i_mode))
asmlinkage int sys_close(unsigned int fd)
{
struct file * filp;
+ struct inode * inode;
if (fd >= NR_OPEN)
return -EBADF;
FD_CLR(fd, &current->close_on_exec);
if (!(filp = current->filp[fd]))
return -EBADF;
+ inode = filp->f_inode;
+ if (filp->f_flags & FASYNC)
+ if (filp->f_op && filp->f_op->async)
+ filp->f_op->async(inode, filp, 0);
current->filp[fd] = NULL;
return (close_fp (filp, fd));
}
diff -r -u -N linux.unhacked/include/linux/fs.h
linux/include/linux/fs.h
--- linux.unhacked/include/linux/fs.h Sat Mar 19 18:43:44 1994
+++ linux/include/linux/fs.h Sun Mar 20 19:45:51 1994
@@ -213,6 +213,7 @@
struct file *f_next, *f_prev;
struct inode * f_inode;
struct file_operations * f_op;
+ signed int f_owner;
/* needed for tty driver, and maybe others */
void *private_data;
};
@@ -276,6 +277,7 @@
int (*open) (struct inode *, struct file *);
void (*release) (struct inode *, struct file *);
int (*fsync) (struct inode *, struct file *);
+ void (*async) (struct inode *, struct file *, int);
};
struct inode_operations {
+extern inline void async_add_wait_queue(struct wait_queue ** p,
struct wait_queue * wait)
+{
+ unsigned long flags;
+
+#ifdef DEBUG
+ if (wait->next) {
+ unsigned long pc;
+ __asm__ __volatile__("call 1f\n"
+ "1:\tpopl %0":"=r" (pc));
+ printk("add_wait_queue (%08x): wait->next =
%08x\n",pc,(unsigned long) wait->next);
+ }
+#endif
+ save_flags(flags);
+ cli();
+ if (!*p) {
+ wait->next = wait;
+ *p = wait;
+ } else {
+ wait->next = (*p)->next;
+ (*p)->next = wait;
+ }
+ wait->flags = 1;
restore_flags(flags);
}
diff -r -u -N linux.unhacked/include/linux/tty.h
linux/include/linux/tty.h
--- linux.unhacked/include/linux/tty.h Sat Mar 19 18:43:45 1994
+++ linux/include/linux/tty.h Sun Mar 20 23:09:00 1994
@@ -309,6 +309,8 @@
int (*select)(struct tty_struct * tty, struct inode *
inode,
struct file * file, int sel_type,
struct select_table_struct *wait);
+ void (*async)(struct tty_struct * tty, struct inode *
inode,
+ struct file * file, int on_off);
/*
* The following routines are called from below.
*/
diff -r -u -N linux.unhacked/include/linux/wait.h
linux/include/linux/wait.h
--- linux.unhacked/include/linux/wait.h Thu Feb 10 23:57:58 1994
+++ linux/include/linux/wait.h Sun Mar 20 20:44:01 1994
@@ -8,6 +8,7 @@
struct wait_queue {
struct task_struct * task;
+ int flags;
struct wait_queue * next;
};
sched.c:
@@ -344,17 +348,21 @@
return;
do {
if ((p = tmp->task) != NULL) {
- if (p->state == TASK_INTERRUPTIBLE) {
- p->state = TASK_RUNNING;
- if (p->counter > current->counter)
- need_resched = 1;
+ if (tmp->flags)
+ send_sig(SIGIO, tmp->task, 1);
+ else {
+ if (p->state == TASK_INTERRUPTIBLE) {
+ p->state = TASK_RUNNING;
+ if (p->counter >
current->counter)
+ need_resched = 1;
+ }
}
}
if (!tmp->next) {
- printk("wait_queue is bad (eip =
%08lx)\n",((unsigned long *) q)[-1]);
- printk(" q = %p\n",q);
- printk(" *q = %p\n",*q);
- printk(" tmp = %p\n",tmp);
+ printk(KERN_ERR "wait_queue is bad (eip =
%08lx)\n",((unsigned long *) q)[-1]);
+ printk(KERN_ERR " q = %p\n",q);
+ printk(KERN_ERR " *q = %p\n",*q);
+ printk(KERN_ERR " tmp = %p\n",tmp);
break;
}
tmp = tmp->next;
------------------------------
From: hurtta@dionysos.fmi.fi (Kari E. Hurtta)
Subject: Magic of .. (Re: Amiga FileSystem, Anyone?)
Date: 26 Mar 1994 20:51:32 GMT
gt8134b@prism.gatech.edu (Robert Sanders) writes:
;kevin@frobozz.sccsi.com (Kevin Brown) writes:
;>The "." and ".." restriction is a bit tougher to get around, however...
;Er, what? Linux isn't like DOS, and those aren't special reserved names. Those
;are links created when you make the directory: "." is a link to the directory
;containing it, and ".." is a link to the parent directory, unless you're in /
;when it's a link to ".".
No. There must be special interpreting of ".." because kernel must keep
track of chrooted environments. Another point, where special interpreting
of ".." is required, is mountpoints.
--
- Kari E. Hurtta / Eldmd on monimutkaista
Kari.Hurtta@Fmi.FI puh. (90) 1929 658
------------------------------
From: torvalds@klaava.Helsinki.FI (Linus Torvalds)
Subject: Re: Proposal - Coordinating bug fixes with enhancements.
Date: 27 Mar 1994 11:44:37 +0300
In article <HJSTEIN.94Mar22183141@sunset.huji.ac.il>,
Harvey J. Stein <hjstein@sunset.huji.ac.il> wrote:
>
>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.
...
There is already a "official" way to do this, which is
1.0 Stable (hope)
1.0.x minor bugfixes
1.1 development
1.1.x bugfixes, new features, more development
After 1.1.x seems to be stable, we rename the last version as
1.2 Stable
1.2.x minor bugfixes
1.3 development
1.3.x bugfixes, new features, more development
etc.. So even minor numbers would be stable releases, while odd minor
numbers would be development releases. Both have patchlevels, but the
stable releases would have only bugfixes.
In fact, the above has already taken effect: there is a "v1.0" directory
on ftp.funet.fi and ftp.cs.helsinki.fi which contains the 1.0 fixes:
four small patches so far, and a fifth probably appearing today. The
four first ones help stabilize networking on busy nets, while the fifth
one has a few assorted bugfixes.
1.0 seems reasonably stable even as it is, but the idea would be that
most people could upgrade with at least the 1.0.x patches, as those
should be safe. The "live on the edge" people would get the 1.1 sources
(which I haven't made yet, but will make next week).
Linus
------------------------------
From: phil@zeus.fasttax.com (Phil Howard)
Subject: Re: program to watch IRQs
Date: 27 Mar 1994 03:23:32 -0600
soup@penrij.UUCP (John R. Campbell) writes:
>dmarcher@acsu.buffalo.edu (dave archer) writes:
>
>>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.)
>
>There have been times I would've liked to get this information.
>
>Perhaps a /proc device with one entry per IRQ, 16 counters in the
>Interrupt dispatch logic?
>
>For a networked system, you can get a "feel" for the overhead of
>being attached to the ether...
Once I get upgraded to 1.0 I plan to dive into some kernel developments.
One of the ideas on the drawing board is a special virtual terminal that
would be dedicated to kernel monitoring. Maybe more than one VT could be.
But what would you like to see? Perhaps a list of counts per IRQ number?
Maybe also a smoothed interrupts per second? Maybe a graphical chart that
shows interrupts? I'm sure this could be done.
I was wanting to try to reproduce a process run/dispatch display much
like the job dispatch display from the old CDC Cyber displays. Just
what can be displayed usefully is still in question.
--
Phil Howard KA9WGN | "It is good to keep a gun for peaceful purposes,
Unix/Internet System Admin | not for aggression" --Mikhail Kalashnikov,
CLR/Fast-Tax | designer of the Avtomat Kalashnikova 1947, while
phil@fasttax.com | at the Dallas 1994 Shot Show, Wed 12 Jan 1994.
------------------------------
From: jmantel@world.std.com (Jaime C Mantel)
Subject: linux on macintosh?
Date: Sun, 27 Mar 1994 10:44:44 GMT
I have been asked by a friend to ask the following question. Is there a
version of linux for the Macintosh? And if so where can one get it?
------------------------------
From: jmantel@world.std.com (Jaime C Mantel)
Subject: linux and macintosh
Date: Sun, 27 Mar 1994 10:46:39 GMT
Sorry, I forgot to put my address on the posting with the question about
linux on the mac.
jmantel@world.std.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
******************************