From: Digestifier To: Linux-Activists@news-digests.mit.edu Reply-To: Linux-Activists@news-digests.mit.edu Date: Sat, 18 Apr 92 17:15:10 EDT Subject: Linux-Activists Digest #83 Linux-Activists Digest #83, Volume #2 Sat, 18 Apr 92 17:15:10 EDT Contents: Remote login (Scott Silverstein MD) Re: telecomm in Linux, users (Michael Pereckas) Re: Graphics and IPC questions... (Michael Pereckas) Patch to add Dvorak keyboard (Michael Pereckas) Re: IDE-drive performance with linux (Guido Kueppers) rudimentary runlevel patches to init [poe-igl-1.2] (qpliu@phoenix.princeton.edu) ---------------------------------------------------------------------------- From: scott@grip.cis.upenn.edu (Scott Silverstein MD) Subject: Remote login Date: 18 Apr 92 14:36:25 GMT Is LINUX 0.95 now at a stage where it can comfortably handle remote logins via modem on com1/2? I would like the try to use it in that fashion, and perhaps to port over a UNIX bbs. ------------------------------ From: mper@uipsuxb.ps.uiuc.edu (Michael Pereckas) Subject: Re: telecomm in Linux, users Date: Sat, 18 Apr 1992 16:42:50 GMT alsaggaf@ERL.MIT.EDU (M. Saggaf) writes: >I have a couple of questions about Linux. First, kermit does not work. >It runs fine at first but it cannot even "connect". It times out after >issuing the command "connect" with the message "cannot get char: >EAGAIN", or something like that. Does that happen to everybody? I'm not >using kermit5A by the way (that one terminates with a segmentation >fault). xc runs fine. I have a hayes-compatible modem at com1 (ttys1). >Also, zmodem (rz) does not work. It also times out. Any suggestions >would be greatly apprecuated. I've been using mskermit and zmodem >under DOS for quite some time with no problems. It works fine for me. Are you sure you have kermit set to use the right port and speed? Also, there is a new kermit5A binary that works correctly. Zmodem works for me, too. Remember that unlike with DOS, you have to redirect stdin and stdout to the serial device, for example, rz /dev/ttys1 >Second, how can I setup a user account other than root? -- i.e. how to >setup the /etc/passwd file, .. etc? Thank you. There is an adduser program, but (it might have been changed by now) it has bugs and it won't compile as distributed. You need to mess with the makefile and get and compile the poegil (sp) stuff first. The simplest way is to edit /etc/passwd manually. As root (only root should be able to write to it) us an editor to add a line for a new user. The format is: user:passwd:uid:gid:user's real name:home directory:login shell user is the login name. The uid is the user id, and should be unique to the user. The group id is the numeric group identifier that this user is in. Leave the password field blank---the password is stored in encyypted form. Use the passwd program to change the password from blank to whatever you want. There is a passwd program available now, but I forget exactly which package it is in. Someone who knows should please post the answer. The real name would be used by the finger program if we had one, and is not really important. For example: msp::10:10:Michael Pereckas:/home/msp:/usr/bin/bash After using the passwd program to set the password, the second field is filled with random-looking letters. Now create the home directory, in this example /home/msp. (normally, the home directory has the same name as the login name, so msp gets /home/msp, bob gets /home/bob... You can use any directory at all, which can sometimes be useful.) After creating the directory, use chown and chgrp (change owner and change group) to make the owner of the user's home directory the user, and the group the user's group. example: cd /home mkdir msp chown msp msp chgrp 10 msp (msp in is group number 10) To add a new group: Add a line to /etc/group group:optional passwd:gid:list of members I don't fully understand this, and we don't have newgrp yet, so just follow this example: users::10: Which gives group 10 the name "users". I welcome corrections and clarifications. Michael Pereckas ------------------------------ From: mper@uipsuxb.ps.uiuc.edu (Michael Pereckas) Subject: Re: Graphics and IPC questions... Date: 18 Apr 92 17:16:39 GMT tml@tik.vtt.fi (Tor Lillqvist) writes: >In article <1992Apr17.150859.23801@ux1.cso.uiuc.edu> chojnows@osiris (Brian Chojnowski) writes: > I plan to add a direct to screen library. Basically I envision > creating a terminal type that is a superset of vt100. Nothing as fancy or > system hog like X. Just a characterset based graphix system. So while we are > at it, if anyone has some info somewhere on how to write assembly stuff > under linux, I can start porting some of my dos-mode screen routines. >Ugh. Isn't that a step backward? Why create a completely new, >nonstandard, *local-only*, graphics library? I don't think there is >much chance that people will write programs for Linux that use your >direct-to-screen library. To put it bluntly, if you want to fiddle >with direct hardware access assembler routines, stick to DOS. Even if >you don't need networked graphics, I'm certain a significant fraction >of the Linux community wants it. I like X, I think we need X, I want to rux X, but I can't rux X on my computer, and I can't (yet) affort to upgrade. Hopefully, by the time X in running on Linux, I'll be able to upgrade to run it, but maybe not, and there are others who can't. What some people are suggesting is a way to get a dvi previewer, and maybe a few other graphics-using programs running under Linux on *small* systems. Small take precidence over portable, standard, and powerful in this application. Michael Pereckas ------------------------------ From: mper@uipsuxb.ps.uiuc.edu (Michael Pereckas) Subject: Patch to add Dvorak keyboard Date: Sat, 18 Apr 1992 20:26:45 GMT This patch for linux/kernel/chr_drv/keyboard.S does two things: it causes the ./del key on the keypad to produce a period, instead of a comma, and it adds a Dvorak keyboard. The first change will probably appeal to US users. Others may prefer the comma. If there is a lot of difference of opinion on this, maybe num_table should be moved into the national keyboard definitions. The second change is great if you, like me, like the Dvorak keyboard layout. Unfortunatly, the only way to change keyboards is to reboot with a different kernel, so the Dvorak keyboard is a problem is more than one person use the machine and they don't all know Dvorak. (this only effects the console, serial port connections are uneffected.) I post this on the off chance that someone is interested. If you choose to use this, remember that although it seems to work fine for me, this is an example of "programming by meta-w", that is, I copied the US keyboard definition (using the emacs command meta-w) and modified it, without really understanding it. This patch is for linux/kernel/chr_drv/keyboard.S It works for all the 0.95* versions, I think (!) ********** CUT HERE ********** *** keyboard.S.ori Wed Apr 8 16:57:58 1992 --- keyboard.S Wed Apr 8 17:03:10 1992 *************** *** 18,23 **** --- 18,24 ---- * KBD_FR for Frech keyboard * KBD_UK for British extended keyboard * KBD_DK for Danish keyboard + * KBD_DVORAK for Dvorak (US) keyboard */ .text *************** *** 251,257 **** .ascii "789-456+1230." #else num_table: ! .ascii "789-456+1230," #endif cur_table: .ascii "HA5-DGC+YB623" --- 252,258 ---- .ascii "789-456+1230." #else num_table: ! .ascii "789-456+1230." #endif cur_table: .ascii "HA5-DGC+YB623" *************** *** 611,616 **** --- 612,667 ---- .byte 0,0,0,0,0 /* 4A-4E */ .byte 0,0,0,0,0,0,0 /* 4F-55 */ .ascii "\\" + .fill 10,1,0 + + #elif defined(KBD_DVORAK) + + key_map: + .byte 0,27 + .ascii "1234567890\\=" + .byte 127,9 + .ascii "',.pyfgcrl/]" + .byte 13,0 + .ascii "aoeuidhtns-" + .byte '`,0 + .ascii "[;qjkxbmwvz" + .byte 0,'*,0,32 /* 36-39 */ + .fill 16,1,0 /* 3A-49 */ + .byte '-,0,0,0,'+ /* 4A-4E */ + .byte 0,0,0,0,0,0,0 /* 4F-55 */ + .byte '< + .fill 10,1,0 + + shift_map: + .byte 0,27 + .ascii "!@#$%^&*()|+" + .byte 127,9 + .ascii "\"<>PYFGCRL?}" + .byte 13,0 + .ascii "AOEUIDHTNS_" + .byte '~,0 + .ascii "{:QJKXBMWVZ" + .byte 0,'*,0,32 /* 36-39 */ + .fill 16,1,0 /* 3A-49 */ + .byte '-,0,0,0,'+ /* 4A-4E */ + .byte 0,0,0,0,0,0,0 /* 4F-55 */ + .byte '> + .fill 10,1,0 + + alt_map: + .byte 0,0 + .ascii "\0@\0$\0\0{[]}\\\0" + .byte 0,0 + .byte 0,0,0,0,0,0,0,0,0,0,0 + .byte '~,13,0 + .byte 0,0,0,0,0,0,0,0,0,0,0 + .byte 0,0 + .byte 0,0,0,0,0,0,0,0,0,0,0 + .byte 0,0,0,0 /* 36-39 */ + .fill 16,1,0 /* 3A-49 */ + .byte 0,0,0,0,0 /* 4A-4E */ + .byte 0,0,0,0,0,0,0 /* 4F-55 */ + .byte '| .fill 10,1,0 #else ------------------------------ From: UPP200@ibm.rhrz.uni-bonn.de (Guido Kueppers) Subject: Re: IDE-drive performance with linux Date: 18 Apr 92 16:31:28 GMT Meanwhile I have tried to come up with some figures for the IDE drive performance problem. What I did was copying /dev/kmem (4MB) to disk and in a second step to copy the resulting file (kmem.dump) from one partition to another. Running this test on the MFM drive as well as on the IDE drive showed that the former was definitely faster. On both setups I used the same kernel, compiled from the unmodified 0.95c+ source found on tsx-11.mit.edu. There were no other processes running except for /etc/update, which I had no way to kill on the setup with the MFM drive. This is what I've got: This is a test with the Seagate ST251 MFM drive and WD1006V controller: ======= bash#df inodes inodes inodes blocks blocks blocks mount devices total used free total used free point =================================================================== /dev/hda1 6525 125 6400 199575 1373 18202 / dev/hda2 7395 3 7392 22185 239 21946 mnt/ bash# sync bash# time cp /dev/kmem /kmem.dump <--- write 4MB from memory to disk 0.17u 55.08s 1:00.25 8pf ^^^^^^^ bash# ls -l /kmem.dump -rw------- 1 root root 4194304 Apr 17 21:06 /kmem.dump bash# sync bash# time cp /kmem.dump /mnt/ <--- copy a 4MB file from hda1 to hda2 0.18u 10.12s 2:35.36 8pf ^^^^^^^ bash# This is the same test performed on a Rodime 3259A IDE drive: ======= / # df inodes inodes inodes blocks blocks blocks mount device total used free total used free point ================================================================== /dev/hda2 18504 163 18341 55512 14094 41418 / /dev/hda3 18504 706 17798 55512 19165 36347 /usr /dev/hda4 18576 1007 17569 55728 18105 37623 /usr/local / # sync / # time cp /dev/kmem /kmem.dump 0.19u 62.66s 1:28.08 8pf <--- About 50% more than with the MFM drive / # ls -l /kmem.dump -rw------ 1 root root 4194304 Apr 17 21:30 /kmem.dump / # sync / # time cp /kmem.dump /usr/local/bin/ 0.23u 14.18s 2:58.79 8pf <--- about 30 secs more than with the MFM drive I don't know what this sort of testing is worth after all, but it seems to substantiate my doubts about IDE drive performance. Perhaps the problem lies with the particular drive I'm using. Perhaps it has to do with the IDE drive's internal buffering scheme. Someone willing to comment on this? Guido ------------------------------ From: qpliu@phoenix.princeton.edu Subject: rudimentary runlevel patches to init [poe-igl-1.2] Reply-To: qpliu@princeton.edu Date: Sat, 18 Apr 1992 03:53:52 GMT These minor hacks make init of poe-igl-1.2 support a rudimentary form of runlevels. Doing vi /etc/inittab, kill -1 1, vi /etc/inittab, ... is bothersome. The old inittab entries are assumed to be for runlevel 1. The first entry is used for all runlevels. In order to specify the runlevels for an entry, start the entry with a colon, followed by characters specifying the runlevels, followed by a colon and the rest of the entry. init starts at runlevel 0 if the exit status for /etc/rc is nonzero, otherwise it reads the runlevel from /etc/rl, if it exists, otherwise it starts at runlevel 1. runlevel is a simple-minded script to change the runlevel. qpliu@princeton.edu *** pathnames.h.orig Thu Apr 16 21:02:32 1992 --- pathnames.h Thu Apr 16 20:24:36 1992 *************** *** 37,39 **** --- 37,40 ---- #define _PATH_LOGIN "/bin/login" #define _PATH_INITTAB "/etc/inittab" #define _PATH_RC "/etc/rc" + #define _PATH_RL "/etc/rl" *** simpleinit.c.orig Thu Apr 16 20:54:09 1992 --- simpleinit.c Thu Apr 16 22:56:03 1992 *************** *** 17,22 **** --- 17,23 ---- #define CMDSIZ 150 #define NUMCMD 30 #define NUMTOK 20 + #define MAX_LEVS 31 #define RUN_RC *************** *** 28,41 **** char termcap[30]; char *toks[NUMTOK]; char line[CMDSIZ]; }; struct initline inittab[NUMCMD]; int numcmd; int stopped = 0; /* are we stopped */ void do_rc(), spawn(), hup_handler(), read_inittab(); ! void tstp_handler(); void err(char *s) { --- 29,44 ---- char termcap[30]; char *toks[NUMTOK]; char line[CMDSIZ]; + char levels[MAX_LEVS + 1]; }; struct initline inittab[NUMCMD]; int numcmd; int stopped = 0; /* are we stopped */ + char level = '0'; void do_rc(), spawn(), hup_handler(), read_inittab(); ! void tstp_handler(), int_handler (), get_level (); void err(char *s) { *************** *** 53,58 **** --- 56,62 ---- int vec,i; pid_t pid; + signal(SIGINT, SIG_IGN); #ifdef RUN_RC do_rc(); #endif *************** *** 68,77 **** --- 72,83 ---- printf("toks= %s %s %s %s\n",p[0], p[1], p[2], p[3]); printf("tty= %s\n", inittab[i].tty); printf("termcap= %s\n", inittab[i].termcap); + printf("level=%c, levels=\"%s\"\n", level, inittab[i].levels); } exit(0); #endif signal(SIGHUP, hup_handler); + signal(SIGINT, int_handler); signal(SIGTSTP, tstp_handler); for(i = 0; i < numcmd; i++) *************** *** 84,90 **** if(pid == inittab[i].pid || inittab[i].pid < 0) { if(stopped) inittab[i].pid = -1; else spawn(i); - break; } } } --- 90,95 ---- *************** *** 113,118 **** --- 118,124 ---- } else if(pid > 0) { /* parent, wait till rc process dies before spawning */ while(wait(&stat) != pid) /* nothing */; + if (!stat&0xff) get_level (); } } *************** *** 120,126 **** { pid_t pid; int j; ! if((pid = fork()) < 0) { inittab[i].pid = -1; err("fork failed\n"); --- 126,137 ---- { pid_t pid; int j; ! ! if (i && !strchr(inittab[i].levels, level)) { ! inittab[i].pid = -1; ! return; ! } ! if((pid = fork()) < 0) { inittab[i].pid = -1; err("fork failed\n"); *************** *** 173,179 **** if(fgets(buf, CMDSIZ - 1, f) == 0) break; if(buf[0] == '#' || buf[0] == '\n') continue; ! (void) strcpy(inittab[i].line, buf); (void) strtok(inittab[i].line, ":"); (void) strncpy(inittab[i].tty, inittab[i].line, 9); --- 184,202 ---- if(fgets(buf, CMDSIZ - 1, f) == 0) break; if(buf[0] == '#' || buf[0] == '\n') continue; ! if (buf[0] == ':') { ! char *e = strchr (buf + 1, ':'); ! int l = MAX_LEVS; ! if (e) { ! l = e - buf - 1; ! if (l > MAX_LEVS) l = MAX_LEVS; ! } ! strncpy (inittab[i].levels, buf + 1, l); ! (void) strcpy(inittab[i].line, e + 1); ! } else { ! strcpy (inittab[i].levels, "1"); ! (void) strcpy(inittab[i].line, buf); ! } (void) strtok(inittab[i].line, ":"); (void) strncpy(inittab[i].tty, inittab[i].line, 9); *************** *** 227,232 **** --- 250,256 ---- } if(!had_already) spawn(i); } + stopped = 0; (void) signal(SIGHUP, hup_handler); } *************** *** 237,240 **** --- 261,292 ---- if(!stopped) hup_handler(); signal(SIGTSTP, tstp_handler); + } + + void + int_handler () + { + int i; + + signal (SIGINT, SIG_IGN); + get_level (); + + for (i = 0; i < numcmd; i++) + if (inittab[i].pid < 0) spawn (i); + + stopped = 0; + signal (SIGINT, int_handler); + } + + void + get_level () + { + FILE *rl; + char b[2]; + + level = '1'; + if ((rl = fopen (_PATH_RL, "r")) && fgets (b, 1, rl)) + level = b[0]; + fclose (rl); + return; } *** /dev/null Thu Apr 16 23:02:42 1992 --- runlevel Thu Apr 16 22:02:12 1992 *************** *** 0 **** --- 1,10 ---- + #!/bin/sh + USAGE="Usage: $0 level" + _PATH_RL=/etc/rl + + if [ $# = 0 ]; then echo $USAGE; exit 1; fi + + umask 022 + echo $1 > $_PATH_RL + + kill -2 1 *** inittab.orig Thu Apr 16 22:31:45 1992 --- inittab Thu Apr 16 22:47:03 1992 *************** *** 1,10 **** # inittab for linux, poeigl 1.2 # Format: # ttyline:termcap-entry:getty-command tty1:con80x60:/bin/agetty 9600 tty1 ! tty2:con80x60:/bin/agetty 9600 tty2 ! tty3:con80x60:/bin/agetty 9600 tty3 ! tty4:con80x60:/bin/agetty 9600 tty4 # tty5:con80x60:/bin/agetty 9600 tty5 ! tty64:dumb:/bin/agetty 9600 tty64 ! # tty65:dumb:/bin/agetty -m -t60 2400 tty65 --- 1,15 ---- # inittab for linux, poeigl 1.2 # Format: # ttyline:termcap-entry:getty-command + # or + # :levels:ttyline:termcap-entry:getty-command tty1:con80x60:/bin/agetty 9600 tty1 ! :1ldn:tty2:con80x60:/bin/agetty 9600 tty2 ! :1ldn:tty3:con80x60:/bin/agetty 9600 tty3 ! :1ldn:tty4:con80x60:/bin/agetty 9600 tty4 # tty5:con80x60:/bin/agetty 9600 tty5 ! :ldn:tty64:dumb:/bin/agetty 9600 tty64 ! :d:tty65:dumb:/bin/agetty -m -t60 2400 tty65 ! :n:ttyp0:dumb:/bin/agetty 9600 ttyp0 ! :n:ttyp1:dumb:/bin/agetty 9600 ttyp1 ! :n:ttyp2:dumb:/bin/agetty 9600 ttyp2 *** Makefile.orig Thu Apr 16 21:31:08 1992 --- Makefile Thu Apr 16 21:34:55 1992 *************** *** 17,28 **** ${CC} ${CFLAGS} -c $*.c all: libufc.a login who encrypt last agetty hostname init getlogin.o \ ! write install: all strip login who encrypt last agetty hostname init write ! cp login init agetty /bin ! chmod 744 /bin/init /bin/agetty chmod u+s /bin/login cp who encrypt hostname last write users mesg /usr/bin ln -s /usr/bin/write /usr/bin/wall --- 17,28 ---- ${CC} ${CFLAGS} -c $*.c all: libufc.a login who encrypt last agetty hostname init getlogin.o \ ! write runlevel install: all strip login who encrypt last agetty hostname init write ! cp login init agetty runlevel /bin ! chmod 744 /bin/init /bin/agetty /bin/telinit chmod u+s /bin/login cp who encrypt hostname last write users mesg /usr/bin ln -s /usr/bin/write /usr/bin/wall -- qpliu@princeton.edu ------------------------------ ** 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-Activists-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux) via: Internet: Linux-Activists@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 tupac-amaru.informatik.rwth-aachen.de pub/msdos/replace The current version of Linux is 0.95a released on March 17, 1992 End of Linux-Activists Digest ******************************