574 lines
22 KiB
Plaintext
574 lines
22 KiB
Plaintext
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, ¤t->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
|
|
******************************
|