Subject: Linux-Development Digest #791
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, 4 Jun 94 06:13:05 EDT

Linux-Development Digest #791, Volume #1          Sat, 4 Jun 94 06:13:05 EDT

Contents:
  Re: Thanks to Alan Cox & NetCrew! (Dances With Geeks)
  Re: Does linux work in laptop w/ IBM BIOS? (Brad Pepers)
  Re: ncurses 1.8.1 (Zenon Fortuna)
  Re: iscntrl(128) thru iscntrl(255) (Ken Pizzini)
  Linux and net status checker? (Richard Whittaker)
  Kernel change summary 1.1.17 -> 1.1.18 (Russell Nelson)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Bjorn Ekwall)
  NFS over TCP!!! (Re: NFS and PPP on Linux REALLY slow) (Frank Lofaro)
  Re: Why is Linux monolithic? (John Richardson)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Alex Ramos)
  Re: 1.1.17 and no networking won't compile (Bjorn Ekwall)
  Re: Let's rename v1.0.9! [Was: Frustrated with new kernels] (Kevin Lentin)
  Re: The visual bell: patch and RFD (Dennis Henriksen)

----------------------------------------------------------------------------

From: lilo@slip-2-28 (Dances With Geeks)
Subject: Re: Thanks to Alan Cox & NetCrew!
Date: 4 Jun 1994 02:42:40 GMT

On Sat, 4 Jun 1994 01:56:20 GMT, John Grosen (grosen@toons.cc.ndsu.NoDak.edu) wrote:

> Just a quick word of thanks to Alan Cox and all the other folks who have
> done such a great job on the network code in Linux. It's been a rocky road
> but it's been worth it. Tonight, I am sitting at home on my measly '386
> running X, and reading news via slip from a '486 running Linux and acting as
> a slip server/gateway. What more can you ask for! It's outstanding!

And I'm having a wonderful time telnetting in from the PC's at school...I
ran rtin from a PC at school with a GUI and had my first experience reading
news on a 132x40 or so character screen....it was GREAT!!

My kmem-ps is back up, and as far as I'm concerned 1.1.17 is beautiful!

Thanks, everybody!! :)


lilo

------------------------------

From: pepersb@cuug.ab.ca (Brad Pepers)
Subject: Re: Does linux work in laptop w/ IBM BIOS?
Date: Tue, 31 May 1994 18:13:08 GMT

>Somebody sent me a solution (I lost his name with the letter though,
>sorry). It is really very simple. To hd.c add the line:

Its a fix I came up with. It seems to cure the booting on some IBM
systems but not others. In house we have 3 Valuepoints and 1 Thinkpad.
This fix make two of the Valuepoints work and the Thinkpad as well. I
have no idea why the one Valuepoint doesn't work. It seems to have
really bogus head,cyl,sector values while the others are fine. All I
can think of is that all the machines that work have had SCO loaded
on them at one time or another. Maybe SCO does something to fix the
CMOS info up...

>What this means is simple, if the number of cylenders for that drive
>in CMOS is not zero, this means a drive is attached. Bingo, instant
>solution to all those IBM machines problems. Don't you think this
>ought to be standard in the kernel? Linus?

Since it will fix some cases and will not hurt anything that does have
the CMOS set up normally maybe it should be part of the regular kernel?

>-Steve
>

+----------------------------Ren & Stimpy--------------------------------+
| "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the   |
| cheese. And you're the lemon merchant. Get it? And he knows it. That's |
| why he's gonna kill us. So we gotta beat it. Yeah. Before he lets      |
| loose the marmosets on us! Don't worry, little missy! I'll save you!"  |
+------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+

------------------------------

From: zenon@resonex.com (Zenon Fortuna)
Subject: Re: ncurses 1.8.1
Date: Thu, 2 Jun 1994 10:00:54 GMT

In article <2shm4q$fh0@news.cs.tu-berlin.de>,
centauri <centauri@cs.tu-berlin.de> wrote:
>Hi,
>
>I'm having some problems with ncurses.

You should not waste time wrestling with ncurses 1.8.1.
Get ncurses 1.8.5 from netcom.com:/pub/zmbenhal/ncurses/1.8.5.tgz

        Zenon

------------------------------

From: ken@chinook.halcyon.com (Ken Pizzini)
Subject: Re: iscntrl(128) thru iscntrl(255)
Date: 4 Jun 1994 02:29:49 GMT

In article <2so92f$j55@nwfocus.wa.com>,
Ken Pizzini <ken@chinook.halcyon.com> wrote:
>128 characters.  But in the C locale (which is the default)
>the implementer gets a lot of leeway.

Oops -- I forgot: Posix.2 places further constraints on
the POSIX (aka C) locale.  And IEEE Std 1003.2-1992 sec. 2.5.2.1
only defines 0x00-0x1F and 0x7F as cntrl characters in
this locale.  The 0x80..0xFF range are left as "always false".

                --Ken Pizzini

------------------------------

From: rwhittak@orion.docwhitehorse.doc.ca (Richard Whittaker)
Subject: Linux and net status checker?
Date: Sat, 4 Jun 94 03:26:58 GMT

Hello all!

I'm running this box on a fulltime SLIP connection, however, the folks that
Iget the connection from fiddle with the router that I connect to
occasionally.. What I'm looking for is some method to make sure that the
link between myself and the router (over the SLIP link) is still viable, and
exit with a status level if it's not.. This status level would enable the
system to enact a set of instructions to re-establish the link to the remote
end. 

E-Mail is a preferred method of response...

Thanks in advance..

                                        Cheers,
                                        Rich W.
--
Richard Whittaker: Snailmail: 1102 Pine St, Whitehorse YT Y1A 4E8
  Internet E-Mail: rwhittak@orion.docwhitehorse.doc.ca 
Geographic Coords: 60 Deg., 45', 53" N., 135 Deg., 7', 17" W. 
    Amateur Radio: VY1RW, VY1RW@VY1DX, VY1RW@VY1BBS, 145.010 MHz         

------------------------------

From: nelson@crynwr.crynwr.com (Russell Nelson)
Subject: Kernel change summary 1.1.17 -> 1.1.18
Date: 03 Jun 1994 17:39:04 GMT

FPU is now fully re-entrant.
FPU supports 16-bit protected mode.
Sound card CD-ROM driver should work with "Sequoia S-1000",
        which is found on the Spea Media FX sound card.
Much more information in README.sbpcd
Dummy driver added to space.c (so it appears in the list of net drivers).
PPP ioctl added to get stats [why not add it to /proc/net?? -russ]
Buslogic SCSI driver no longer panics on wrong buffer length for
        request sense.
If you define CONFIG_NO_BUGGY_BUSLOGIC, you might have trouble if you
        have more than 16MB (firmware bug).
Fixed set_rtc_mmss, fixed time.year for >= 2000, new mktime
recvfrom() kernel memory protection bug fixed.
Add AX25 support to arp_get_info()
A few bugs in experimental CONFIG_SLAVE_BALANCING device fixed.
Fix for loopback check so it checks for 127.x.x.x instead of 127.0.0.1
        (per the RFC).

--
-russ <nelson@crynwr.com>      ftp.msen.com:pub/vendor/crynwr/crynwr.wav
Crynwr Software   | Crynwr Software sells packet driver support | ask4 PGP key
11 Grant St.      | +1 315 268 1925 (9201 FAX)    | Quakers do it in the light
Potsdam, NY 13676 | LPF member - ask me about the harm software patents do.

------------------------------

From: bj0rn@blox.se (Bjorn Ekwall)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 3 Jun 94 18:39:08 GMT

Alex Frausin (alex@myhost.subdomain.domain) wrote:
 > Thomas Heiling (tom@wpzd07.pzlc.uni-wuerzburg.de) wrote:
 > : : >Bjorn Ekwall == bj0rn@blox.se

 > : : I say let them mess around in their own ignorance.
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I did _not_ write that, neither did Thomas!
Get the attributions right, even if you are in a lousy mood :-)

(s} det s} :-)

Bjorn Ekwall == bj0rn@blox.se

------------------------------

Crossposted-To: comp.os.linux.admin,comp.os.linux.help
From: ftlofaro@unlv.edu (Frank Lofaro)
Subject: NFS over TCP!!! (Re: NFS and PPP on Linux REALLY slow)
Date: Fri, 3 Jun 94 07:27:18 GMT

In article <Cqruyz.E0r@setanta.demon.co.uk> at@setanta.demon.co.uk (Amrik Thethi) writes:
>I wouldn't use NFS over a serial link, PPP or SLIP since Sun NFS
>doesn't use UDP checksums. This is OK for any ethernet network, but
>is likely to cause file corruption on a dodgy phone link. What you
>need is a TCP based NFS, which isn't currently available AFAIK

Well, I've got some ALPHA code I hacked up. The mount is screwed if
the TCP connection closes.  Then all access give EPIPE until it is
umounted and remount. I haven't yet figured out how to best have the
kernel reestablish the TCP connection. Other than that it seems to
work. You need to hack up mount to use a SOCK_STREAM instead of a
SOCK_DGRAM (get the mount source and add that feature, I just quick
hacked that on my system by making a separate TCP NFS mount binary).

NOTE: I posted this also to c.o.l.d since they might like to check out
this code. Please don't follow up there unless its related to kernel
development though. Thanks.

Here's the kernel patch.
It is against one of the 1.1.x patches (x is around 15), but it should
go into newer kernels including 1.1.18 okay. It should also go into
any older kernels as long as they are somewhat recent.

_*NO WARRANTY!!! ALPHA CODE!!!*_

=====BEGIN KERNEL PATCH BLOCK====
diff -r -u -N linux.ref/fs/nfs/sock.c linux/fs/nfs/sock.c
--- linux.ref/fs/nfs/sock.c     Mon Feb 28 22:03:41 1994
+++ linux/fs/nfs/sock.c Sat Apr 30 17:34:09 1994
@@ -3,6 +3,8 @@
  *
  *  Copyright (C) 1992, 1993  Rick Sladkey
  *
+ *  NFS over TCP by Frank Lofaro <ftlofaro@unlv.edu>
+ *
  *  low-level nfs remote procedure call interface
  */
 
@@ -15,6 +17,7 @@
 #include <asm/segment.h>
 #include <linux/in.h>
 #include <linux/net.h>
+#include <linux/malloc.h>
 
 
 extern struct socket *socki_lookup(struct inode *inode);
@@ -31,6 +34,123 @@
  * to the server socket.
  */
 
+
+static inline int do_sock_send(struct socket *sock, void *start, int size, 
+                       int noblock, unsigned flags)
+{
+       int retval;
+       int origsize;
+       origsize=size;
+       while (size) {
+               retval=sock->ops->send(sock, start, size, noblock, flags);
+               if (retval < 0)
+                       return retval;
+               if (!retval) {
+                       printk(KERN_WARNING "do_sock_send: send returns 0!\n");
+                       return -EIO;
+               }
+               size -= retval;
+               start = (void *) ((char *) start) + retval;
+       }
+       return origsize;
+}
+
+static inline int do_sock_recv(struct socket *sock, void *start, int size, 
+                       int noblock, unsigned flags)
+{
+       int retval;
+       int origsize;
+       origsize=size;
+       while (size) {
+               retval=sock->ops->recv(sock, start, size, noblock, flags);
+               if (retval < 0)
+                       return retval;
+               if (!retval) {
+                       printk(KERN_WARNING "do_sock_recv: EOF!\n");
+                       return -EIO;
+               }
+               size -= retval;
+               start = (void *) ((char *) start) + retval;
+       }
+       return origsize;
+}
+
+static inline int do_rpc_send(struct socket *sock, void *start, int size, int noblock,
+                      unsigned flags)
+{
+       unsigned long *reclenptr;       /* Must be 4 bytes. See RFC 1057 */
+       unsigned long save;
+       int retval;
+       if (sock->type == SOCK_STREAM) {
+               if (size < 4)
+                       reclenptr=(long *) kmalloc(sizeof(long), GFP_KERNEL);
+               else {
+                       reclenptr=(unsigned long *) start;
+                       save=*reclenptr;
+               }
+               *reclenptr=htonl(size | (1 << 31));
+               printk(KERN_DEBUG "send size: %d\n", size);
+               printk(KERN_DEBUG "send reclen: %8lx\n", *reclenptr);
+               retval=do_sock_send(sock, reclenptr, 4, noblock, flags);
+               if (size < 4)
+                       kfree(reclenptr);
+               else
+                       *reclenptr=save;
+               printk(KERN_DEBUG "send retval: %d\n", retval);
+               if (retval < 0)
+                       return retval;
+       }
+       return do_sock_send(sock, start, size, noblock, flags);
+}
+
+static inline int do_rpc_recv(struct socket *sock, void *start, int size, int noblock,
+                      unsigned flags)
+{
+       unsigned long *reclenptr;       /* Must be 4 bytes. See RFC 1057 */
+       unsigned long reclen;
+       unsigned int recsize;
+       int more=1;
+       int retval;
+       if (sock->type == SOCK_STREAM) {
+               if (size < 4)
+                       reclenptr=(unsigned long *)
+                               kmalloc(sizeof(long), GFP_KERNEL);
+               else
+                       reclenptr=(unsigned long *) start;
+               retval=do_sock_recv(sock, reclenptr, 4, noblock, flags);
+               printk(KERN_DEBUG "recv retval 1: %u\n", retval);
+               reclen=*reclenptr;
+               printk(KERN_DEBUG "recv reclen: %8lx\n", reclen);
+               if (size < 4)
+                       kfree(reclenptr);
+               if (!retval) {
+                       printk(KERN_WARNING "EOF on NFS STREAM!\n");
+                       return -EIO;
+               }
+               if (retval < 0)
+                       return retval;
+               recsize=ntohl(reclen);
+               more=(!(recsize & (1 << 31)));
+               if (more)
+                       printk(KERN_NOTICE "recv: Fragment!\n");
+               recsize &= ~(1 << 31);
+               printk(KERN_DEBUG "recv recsize: %u\n", recsize);
+               if (recsize > size) {
+                       printk(KERN_WARNING "recv: recsize > size!\n");
+                       return -EIO;
+               }
+               retval=do_sock_recv(sock, start, recsize, noblock, flags);
+               if (!retval) {
+                       printk(KERN_WARNING "recv: EOF on NFS STREAM!\n");
+                       return -EIO;
+               }
+               printk(KERN_DEBUG "recv retval 2: %u\n", retval);
+               return retval;
+       } else {
+               return sock->ops->recv(sock, start, size, noblock, flags);
+       }
+}
+
 static int do_nfs_rpc_call(struct nfs_server *server, int *start, int *end)
 {
        struct file *file;
@@ -81,9 +201,9 @@
        fs = get_fs();
        set_fs(get_ds());
        for (n = 0, timeout = init_timeout; ; n++, timeout <<= 1) {
-               result = sock->ops->send(sock, (void *) start, len, 0, 0);
+               result = do_rpc_send(sock, (void *) start, len, 0, 0);
                if (result < 0) {
-                       printk("nfs_rpc_call: send error = %d\n", result);
+                       printk("nfs_rpc_call: send error = %d\n", -result);
                        break;
                }
        re_select:
@@ -129,8 +249,7 @@
                        remove_wait_queue(entry.wait_address, &entry.wait);
                current->state = TASK_RUNNING;
                addrlen = 0;
-               result = sock->ops->recvfrom(sock, (void *) start, PAGE_SIZE, 1, 0,
-                       NULL, &addrlen);
+               result = do_rpc_recv(sock, (void *) start, PAGE_SIZE, 1, 0);
                if (result < 0) {
                        if (result == -EAGAIN) {
 #if 0
=====END KERNEL PATCH BLOCK====


end.


------------------------------

From: jrichard@cad1.uml.edu (John Richardson)
Subject: Re: Why is Linux monolithic?
Date: 03 Jun 1994 19:10:49 GMT


   Perhaps one advantage of a microkernel is for realtime?  My understanding of the


Possibly...


   80X86 (please correct me if I'm wrong, I'm very weak on the 80X86 architecture)
   is that it has only one external interrupt
   pin, and one interrupt enable flag bit in the EFLAGS register.  This makes
   realtime implementation difficult.  Every time the kernel must protect against
   interrupts it masks them all (the CLI and STI instructions).  For comparison,
   on the pdpd11 the driver for the serial line would only block interrupts
   at level 4 or lower (the serial interface interrupted at priority level 4).  
   Interrupts from higher priority level devices (levels 5-7) could still preempt.


I'm no expert either but there is a PIC that PCs use to (somewhat) 
individually mask interrupts.  I believe linux could set the bitmask
using a linuxy splx() interface but probably doesn't for simplicity.


Any comments?

John Richardson
jrichard@cs.uml.edu


------------------------------

From: ramos@engr.latech.edu (Alex Ramos)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 3 Jun 1994 18:43:11 GMT

Less drastic, and about as effective, would be to just put
a good README file in a real good place...

--
Alex Ramos (ramos@engr.latech.edu) * http://info.latech.edu/~ramos/
Louisiana Tech University, BSEE/Sr * These opinions are probably mine

------------------------------

From: bj0rn@blox.se (Bjorn Ekwall)
Subject: Re: 1.1.17 and no networking won't compile
Date: 3 Jun 94 18:56:58 GMT

Samson H. Lee (shl0@ihd117d.CC.Lehigh.EDU) wrote:
 > I applied patch17 yesterday and tried recompiling the kernel.  I had
 > been including network support for TCP/IP and SLIP but decided to
 > remove network support until I really needed it.  (My university is in
 > the process of setting a SLIP server, but it's not ready yet.)  So I
 > tried leaving it out when I ran 'make config'.  I then ran 'make
 > mrproper' and 'make dep'.  Finally, I ran 'make zImage'.  After an
 > hour of compiling (I on a 486SX-25 w/4MB ram) I got an error that
 > "_dev_init" and "_???" (another symbol) were not defined.  I narrowed
 > it down to function calls in socket.c to functions defined in dev.c
 > which was not compiled because networking was disabled.

It's an oversight... Some kind person has noticed this and suggested that
the dev_init() call in the last lines of "linux/net/socket.c" should be
surrounded with "#ifdef CONFIG_INET" and "#endif".
Sorry, I can't remember who it was, or where...

Bjorn Ekwall == bj0rn@blox.se

------------------------------

From: kevinl@bruce.cs.monash.edu.au (Kevin Lentin)
Subject: Re: Let's rename v1.0.9! [Was: Frustrated with new kernels]
Date: 4 Jun 1994 08:36:25 GMT

Albert D. Cahalan (adc@zeta.coe.neu.edu) wrote:
> Suggestion: version x.y.z is considered stable when y is even, and
> considered hackers paridise when y is odd.  An unstable kernel is odd.  :)
> This way every version x.0 would be considered stable.  (What a concept!
> x.0 software that works)

That's already how it works. 1.0.x are the stable kernels with bugfixes and
1.1.x are the new kernels with new features and bug fixes.

The argument here may be whether the odd or the even kernel should have the
greater number so that people who do not know what is going on would
automatically take the latest stable kernel (hence the call for 1.2.0). I
find this a bit weird. It would be real strange to be developping a kernel
with a version lower than the stable one. To be developping 1.1.x while
1.2.x is out is wrong. And what happens when 1.1.x is declared stable? Make
it 1.4.0 and then the next kernel after 1.4.0 is  1.4.1 for the stable ones
and 1.3.0 for a new feature. It would cause far more confusion than there
is now.

And further, if people are resourceful enough to find all the different
kernels and post to news asking questions then they certainly should have
the resources to get the answer to the question very easily.

-- 
[==================================================================]
[ Kevin Lentin                   |___/~\__/~\___/~~~~\__/~\__/~\_| ]
[ kevinl@bruce.cs.monash.edu.au  |___/~\/~\_____/~\______/~\/~\__| ]
[ Macintrash: 'Just say NO!'     |___/~\__/~\___/~~~~\____/~~\___| ]
[==================================================================]

------------------------------

From: duke@diku.dk (Dennis Henriksen)
Subject: Re: The visual bell: patch and RFD
Date: Sat, 4 Jun 1994 07:52:41 GMT

rubini@ipvvis.UNIPV.IT (Alessandro Rubini) writes:

>Hello linuxers,
>   my own box doesn't have a loudspeaker, but now that I have access to a
>full featured PC I had to turn off the bell from the linux console. It
>has been very easy, and I include the patch below as I think the visual bell
>is a good thing for all of us who go to bed late (most of us :-) and like
>filename completion in the shell.

>However, at times the bell is a good thing, so I wonder how to make it
>dynamically switchable on and off. I thought of two ways, but I can't choose
>between the two:

>- modifying the setterm command is probably the best way, because it is the
>       normal way to access console configuration, and it is already a
>       linux-specific command.  However, it makes use of the escape
>       sequences, which in turn are quite well standardized, and I won't like
>       adding a non-standard escape sequence to the linux console.

>- on the other way, addin an ioctl() of type TIOCLINUX is not useful to
>       the final user without providing a command-line access, and it is not
>       nice to mess setterm with ioctl()'s.

>So I ask some suggestions to all of you who are interested in the matter.

>Please reply by email to save bandwidth, and I'll post a
>summary (and the patch) if there is enough interest.

>----

>I took the patch against the 1.0 kernel, but it applies well (offset -1line)
>to both the 1.0.9 and the 1.1.12. Midway kernels should be allright, too.

>to apply:             cd /usr/src/linux/drivers/char; patch < __this_patch__

>to re-enable the audible bell: "#define CONFIG_NO_VISUALBELL" at the beginning
>       of console.c

>---8<------8<------8<------8<------8<------8<------8<------8<---
>*** console.c.audible  Fri May 13 18:07:21 1994
>--- console.c  Sat May 14 18:18:16 1994
>***************
>*** 992,997 ****
>--- 992,1014 ----
>       }
>  }
>  
>+ #ifndef CONFIG_NO_VISUALBELL
>+ static inline void con_visualbell(const int currcons)
>+ {
>+     unsigned char *p; int i;
>+     unsigned char *screenstart = (unsigned char *)(origin-
>+                (currcons==fg_console 
>+                  ? ((__real_origin - __origin) << 1) 
>+                  : 0));
>+     unsigned char *screenend=screenstart+video_num_columns*video_num_lines*2;
>+ 
>+     for (i=0;i<2;i++)
>+       for (p=screenstart+1;p<screenend+1;p+=2)
>+                 *p = (*p & 0x88) | ((*p << 4) & 0x70) | ((*p >> 4) & 0x07);
>+ 
>+ }
>+ #endif
>+ 
>  void con_write(struct tty_struct * tty)
>  {
>       int c;
>***************
>*** 1034,1040 ****
>--- 1051,1061 ----
>                */
>               switch (c) {
>                       case 7:
>+ #ifdef CONFIG_NO_VISUALBELL
>                               kd_mksound(0x637, HZ/8);
>+ #else
>+                              con_visualbell(currcons);
>+ #endif
>                               continue;
>                       case 8:
>                               bs(currcons);
>---8<------8<------8<------8<------8<------8<------8<------8<---

How about the following addition to /etc/termcap :

:vb=\E7\E[?5h\E[?5l\E[?5h\E[?5l\E[?5h\E[?5l\E[?5h\E[?5l\E8:\

It does the trick for me with out ANY hacking around in the kernel. What
it says is
        1) Save the cursor position (Just a safety precaution)
        2) Change the background color several times
           between normal and reverse
        3) Restore the cusrsor position.

Dennis Henriksen
duke@diku.dk

------------------------------


** 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
******************************
