A new paper comparing Unix kernel designs was published earlier today:
Stergios Papadimitriou and Lefteris Moussiades
Mac OS versus FreeBSD: A Comparative Evaluation
[IEEE] Computer 52(2), 44--53, February 2018
https://doi.org/10.1109/MC.2018.1451648
Despite the title, GNU/Linux also is included in the comparisons. The
abstract is:
>> ...
>> FreeBSD (an open source Unix-like OS) and Apple's Mac OS use similar
>> BSD functionality but take different approaches. FreeBSD implements a
>> traditional compact monolithic Unix kernel, whereas Mac OS builds the
>> BSD Unix functionality on top of the Mach microkernel. The authors
>> provide an in-depth technical investigation of both approaches.
>> ...
Our fellow list member Larry McVoy, and his lmbench suite, are
mentioned in the article, along with results of that suite.
There are about 200 numbers in the two large tables of performance
measurements, and while many are comparable across operating systems,
there are some benchmarks that show up to a 40x difference between
systems on the same hardware.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
pipes in SCO UNIX 3.2V4.2,
It's long, long ago, so excuses for vagueness. I think the issue was
not pipe() perse, but the difference in functionality between 'pipe
filesystem' and streams pipes.
By using pipe() you create a FIFO pipe with certain limitations
(including 5120 write limit). When you open the streams device twice
and ioctl() two file descriptors together you have more flexibility.
Excuses for the possible confusion.
Following the Claude Shannon discussion:
http://www.jaycar.com.au/useless-box/p/GT3706
I tried to explain to the Young Thing (tm) behind the shop counter that it
was invented several decades ago etc, but I suspect it was beyond her
ken...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> [Bob Fano} still has a reverential photograph of Shannpn
> hanging in his office.
Alas, no, Fano died in 2016 at age 98.
More memories: Fano was among the grad students who came to
ice-skating parties at our house in the mid-40s--the house near
Shannon's later abode. I did not really get to know him until
Multics days. His gravelly mafioso voice would scare you off--until
you saw the irrepressible twinkle in his eye. A beloved and
inspiring leader, worthy of Dave Horsfall's calendar.
Doug
>From a piece of code I have in some SCO UNIX 3.2V4.2 source. SCO
doesn't have pipes, but you can simulate them.
int fd[2]
int rc;
struct strfdinsert ins;
queue_t *pointer = (queue_t *)NULL;
rc = -1;
/*
* First open the stream clone device "/dev/spx" twice,
* obtaining the two file descriptors.
*/
if ( (fd[0] = open(SPX_DEVICE, O_RDWR)) < 0)
{
gen_trace(gtr_flag, "-gen_pipe(): -open(fd[0]): %s\n", strerror(errno));
break;
}
if ( (fd[1] = open(SPX_DEVICE, O_RDWR)) < 0)
{
gen_trace(gtr_flag, ">gen_pipe(): -open(fd[1]): %s\n", strerror(errno));
close(fd[0]);
break;
}
/*
* Now link these two streams together with an
* I_FDINSERT ioctl.
*/
ins.ctlbuf.buf = (char *) &pointer; /* no ctl info, just the ptr */
ins.ctlbuf.maxlen = sizeof(queue_t *);
ins.ctlbuf.len = sizeof(queue_t *);
ins.databuf.buf = (char *) 0; /* no data to send */
ins.databuf.len = -1; /* magic: must be -1, not 0, for stream pipe */
ins.databuf.maxlen = 0;
ins.fildes = fd[1]; /* the fd to connect with fd[0] */
ins.flags = 0; /* nonpriority message */
ins.offset = 0; /* offset of pointer in control buffer */
if (ioctl(fd[0], I_FDINSERT, (char * ) &ins) < 0)
{
gen_trace(gtr_flag, ">gen_pipe(): -ioctl(I_FDINSERT): %s\n", strerror(errno));
close(fd[0]);
close(fd[1]);
break;
}
If I'm remembering correctly, miniunix didn't have pipes. The shell faked
it by taking the output of the first program into a file and then using it
as the input for the second.
Didn't really multitask anyhow, so it was pretty much fine.
-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Ian Zimmerman
Sent: Monday, February 26, 2018 11:58 AM
To: tuhs(a)minnie.tuhs.org
Subject: Re: [TUHS] EOF on pipes?
On 2018-02-26 23:03, Rudi Blom wrote:
> From a piece of code I have in some SCO UNIX 3.2V4.2 source. SCO
> doesn't have pipes, but you can simulate them.
Is this a SCO speciality, or are there other UNIXes like that?
Does it not even have pipe() in its libc?
Many years ago (when the dinosaurs were using V6), I had a crazy idea[*]
that a write(fd, 0, NULL) would somehow signal EOF to the reader i.e. a
subsequent read would wait for further data instead of ENOTOBACCO.
Did any *nix ever implement that? I have no idea how it would be done.
Have an ENOGORILLA.
To answer the real question: stream pipes, which became the only
sort of pipe in the Research stream (sic) sometime between the
8/e and 9/e manuals.
The implementation was trivial, because from the beginning the
metadata within a stream admitted delimiters: markers that meant
`when this object reaches read(2) at the head end, return from
read with whatever has already been delivered.' Empty messages
(two consecutive delimiters) were explicitly allowed.
If a stream was marked as using delimeters (and pipes always
were), a delimeter was inserted after every write(2). So
write(2) generated an empty message, and read(2) returned it.
Norman Wilson
Toronto ON
We lost Claude Shannon on this day in 2001. He was a mathematician,
electrical engineer, and cryptographer; he is regarded as the "father" of
information theory, and he pioneered digital circuit design. Amongst
other things he built a barbed-wire telegraph, the "Ultimate Machine" (it
reached up and switched itself off), a Roman numeral computer ("THROBAC"),
the Minivac 601 (a digital trainer), a Rubik's Cube solver, a mechanical
mouse that learned how to solve mazes, and outlined a chess program
(pre-Belle). He formulated the security mantra "The enemy knows the
system", and did top-secret work in WW-2 on crypto and fire-control
systems.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Re: RIP Claude Shannon
> Never heard of Claude Shannon. So a good opportunity to do some
> searching reading to 'catch up'.
Shannon did some amazing work. My field is Information science and without Shannon, it would be a dull field indeed. His masters thesis laid out an elegant use of digital logic for switching systems that we take for granted today, his mathematical theory of communication, while dense, is foundational - ever heard of a bit?, and he actually loved juggling so much he created a juggling machine - what’s not to love? :) All that said, he was also in the right place at the right time and was surrounded by genius.
Will
