TUHS

tuhs@tuhs.org

6420 discussions

by Warren Toomey

here's the e-mail that I sent on to Mark in the hope that it would give him enough information to get his 5th Edition kernel working with a tape device. He has also now joined the list. Welcome aboard, Mark. Warren ----- Forwarded message from Warren Toomey <wkt(a)tuhs.org> ----- On Thu, Jul 10, 2014 at 05:56:04PM -0400, Mark Longridge wrote: > There was no m40.s in v5 so I substituted mch.s for m40.s and that > seemed to create a kernel and it booted but I can't access /dev/mt0. Mark, glad to hear you were able to rebuild the kernel. I've never tried on 5th Edition. Just reading through the 6th Edition docs, it says this: ----- Next you must put in all of the special files in the directory /dev using mknod‐VIII. Print the configuration file c.c created above. This is the major device switch of each device class (block and character). There is one line for each device configured in your system and a null line for place holding for those devices not configured. The block special devices are put in first by executing the fol‐ lowing generic command for each disk or tape drive. (Note that some of these files already exist in the directory /dev. Examine each file with ls‐I with −l flag to see if the file should be removed.) /etc/mknod /dev/NAME b MAJOR MINOR The NAME is selected from the following list: c.c NAME device rf rf0 RS fixed head disk tc tap0 TU56 DECtape rk rk0 RK03 RK05 moving head disk tm mt0 TU10 TU16 magtape rp rp0 RP moving head disk hs hs0 RS03 RS04 fixed head disk hp hp0 RP04 moving head disk The major device number is selected by counting the line number (from zero) of the device’s entry in the block con‐ figuration table. Thus the first entry in the table bdevsw would be major device zero. The minor device is the drive number, unit number or partition as described under each device in section IV. The last digit of the name (all given as 0 in the table above) should reflect the minor device number. For tapes where the unit is dial selectable, a special file may be made for each possible selection. The same goes for the character devices. Here the names are arbitrary except that devices meant to be used for teletype access should be named /dev/ttyX, where X is any character. The files tty8 (console), mem, kmem, null are already correctly configured. The disk and magtape drivers provide a ‘raw’ interface to the device which provides direct transmission between the user’s core and the device and allows reading or writing large records. The raw device counts as a character device, and should have the name of the corresponding standard block special file with ‘r’ prepended. Thus the raw magtape files would be called /dev/rmtX. When all the special files have been created, care should be taken to change the access modes (chmod‐I) on these files to appropriate values. ----- Looking at the c.c generated, it has: int (*bdevsw[])() { &nulldev, &nulldev, &rkstrategy, &rktab, &tmopen, &tmclose, &tmstrategy, &tmtab, /* 1 */ &nulldev, &tcclose, &tcstrategy, &tctab, 0 }; int (*cdevsw[])() { &klopen, &klclose, &klread, &klwrite, &klsgtty, &nulldev, &nulldev, &mmread, &mmwrite, &nodev, &nulldev, &nulldev, &rkread, &rkwrite, &nodev, &tmopen, &tmclose, &tmread, &tmwrite, &nodev, /* 3 */ &dcopen, &dcclose, &dcread, &dcwrite, &dcsgtty, &lpopen, &lpclose, &nodev, &lpwrite, &nodev, 0 }; Following on from the docs, you should be able to make the /dev/mt0 device file by doing: /etc/mknod /dev/tm0 b 1 0 And possibly also: /etc/mknod /dev/rmt0 c 3 0 Cheers, Warren

10 years, 6 months

Compiling the unix v5 kernel

by Warren Toomey

All, just received this from a fellow who isn't on the TUHS mail list (yet). I've answered him about using mknod (after reading the 6e docs: we don't have 5e docs). I thought I'd forward the e-mail here as a record of an attempt to rebuild the 5e kernel. Cheers, Warren ----- Forwarded message from Mark ----- I hope you don't mind me asking you about compiling the unix v5 kernel. I haven't been able to find any documentation for it. I tried this: ./mkconf rk tm tc dc lp ctrl-d # as mch.s # mv a.out mch.o # cc -c c.c # as l.s # ld -x a.out mch.o c.o ../lib1 ../lib2 There was no m40.s in v5 so I substituted mch.s for m40.s and that seemed to create a kernel and it booted but I can't access /dev/mt0. Any pointers are appreciated. Thanks for all your work on early unix, I thought it was very interesting. Mark ----- End forwarded message -----

10 years, 6 months

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

PS: I see I have over-generalized the problem. Doug's original message say "a process could excise itself from a pipeline". So presumably the initiation would come from process2 itself, and it would know when it had no internally-buffered data. So now we're back to the issue of 'either we need a system call to merge two pipes into one, or the process has to hang around and turn itself into a cat'. Noel

10 years, 6 months

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > Making what you are talking about work is gonna be a mess of buffer > management and it's going to be hard to design system calls that would > work and still give you reasonable semantics on the pipe. Consider > calls that want to know if there is data in the pipe Oh, I didn't say it would work well, and cleanly! :-) I mean, taking one element in an existing, operating, chain, and blowing it away, is almost bound to cause problems. My previous note was merely to say that the file descriptor/pipe re-arrangement involved might be easier done with a system call - in fact, now that I think about it, as someone has already sort of pointed out, without a system call to merge the two pipes into one, you have to keep the middle process around, and have it turn into a 'cat'. Thinking out loud for a moment, though, along the lines you suggest.... Here's one problem - suppose process2 has read some data, but not yet processed it and output it towards process3, when you go to do the splice. How would the anything outside the process (be it the OS, or the command interpreter or whatever is initiating the splice) even detect that, much less retrieve the data? Even using a heuristic such as 'wait for process2 to try and read data, at which point we can assume that it no longer has any internally buffered data, and it's OK to do the splice' fails, because process2 may have decided it didn't have a complete semantic unit in hand (e.g. a complete line), and decided to go back and get the rest of the unit before outputting the complete, processed semantic unit (i.e. including data it had previously buffered internally). And suppose the reads _never_ happen to coincide with the semantic units being output; i.e. process2 will _always_ have some buffered data inside it, until the whole chain starts to shut down with EOFs from the first stage? In short, maybe this problem isn't solvable in the general case. In which case I guess we're back to your "Every utility that you put in a pipeline would have to be reworked". Stages would have to have some way to say 'I am not now holding any buffered data', and only when that state was true could they be spliced out. Or there could be some signal defined which means 'go into "not holding any buffered data" state'. At which point my proposed splice() system call might be some use... :-) Noel

10 years, 6 months

Re: [TUHS] Excise process from a pipe

by jnc＠mercury.lcs.mit.edu

> From: Larry McVoy <lm(a)mcvoy.com> > Every utility that you put in a pipeline would have to be reworked to > pass file descriptors around Unless the whole operation is supported in the OS directly: if ((pipe1 = process1->stdout) == process2->stdin) && ((pipe2 = process2->stdout) == process3->stdin) { prepend_buffer_contents(pipe1, pipe2); process1->stdout = process2->stdout; kill_pipe(pipe1); } to be invoked from the chain's parent (e.g. shell). (The code would probably want to do something with process2's stdin and stdout, like close them; I wouldn't have the call kill process2 directly, that could be left to the parent, except in the rare cases where it might have some use for the spliced-out process.) Noel

10 years, 6 months

Subject:unpipeIt'seasy for a process to insert a new process intoapipelineeither upstream or down unpipe

by Doug McIlroy

It's easy for a process to insert a new process into a pipeline either upstrean or downstream. Was there ever a flavor of Unix in which a process could excise itselfa from a pipeline without breaking the pipeline? Doug

10 years, 6 months

Re: [TUHS] soviet computing

by norman＠oclsc.org

Armando P. Stettner: If I've said once, I've said it a million times: DECvax is NOT connected to kremvax. :) ==== Not any more, anyway. Norman Wilson Toronto ON (once upon a time, research!norman)

10 years, 6 months

soviet computing

by Tim Newsham

slightly off-topic but probably of interest to mailing list members: Pioneers of Soviet Computing http://www.sigcis.org/files/SIGCISMC2010_001.pdf -- Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

10 years, 6 months

1st Unix w/ ISO-8859-1 support?

by Dario Niedermann

Keywords: encoding, charset, latin, roman, accented, diacritical Hi! Does anyone know which was the earliest Unix release to support the ISO-8859-1 character set?

10 years, 6 months

Museo dell'Informatica Funzionante - CONTRIBUTE!

by asbesto

Hi there, Sorry for an eventual Offtopic but this is strictly related to our Computer Museum activity... We launched a campaign to get some help for our upcoming initiative, that will be the starting point for a big step forward to a new Museum! So please take time to read it, and please share everywhere to anyone interested! http://igg.me/at/insertcoin love asbesto

10 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

TUHS