Subject: Linux-Development Digest #582 From: Digestifier 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 , Harvey J. Stein 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 ******************************