From cowan at mercury.ccil.org  Mon Aug  1 11:08:46 2016
From: cowan at mercury.ccil.org (John Cowan)
Date: Sun, 31 Jul 2016 21:08:46 -0400
Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp)
In-Reply-To: <CAMYpm87L17V5bOhHbQKKQ=QMbhv8t_x4+D252F=2gCY8GrwLpQ@mail.gmail.com>
References: <CAMYpm87L17V5bOhHbQKKQ=QMbhv8t_x4+D252F=2gCY8GrwLpQ@mail.gmail.com>
Message-ID: <20160801010846.GA15571@mercury.ccil.org>

Rudi Blom scripsit:

> To setup the 'infrastructure might be the tricky part. Many years ago
> I flew from Montreal to Amsterdam and had two stacks of 5-1/4"
> diskettes with me. No papers, confiscated in Amsterdam.

I carried an RK05 disk full of proprietary software from West Orange NJ
to a client in Kansas City back in 1977.  Airport security existed, but
it wasn't as anal it is today.  So when I told them they couldn't X-ray
the disk, it might scramble it, they wanted to do a physical inspection --
but I told them if they opened the disk they'd get dust in it and ruin it.
Finally they took my word for it.

When the disk got to the client's, it was completely scrambled anyway.
I went back home, and next week my partner went out with a stack of 5.25s.
It took him twenty hours to set up the client's system (I don't remember
if it was a PDP-8 or a PDP-11), but the job got done.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
But no living man am I!  You look upon a woman.  Eowyn I am, Eomund's daughter.
You stand between me and my lord and kin.  Begone, if you be not deathless.
For living or dark undead, I will smite you if you touch him.


From rudi.j.blom at gmail.com  Mon Aug  1 17:14:34 2016
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Mon, 1 Aug 2016 14:14:34 +0700
Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp)
In-Reply-To: <20160801010846.GA15571@mercury.ccil.org>
References: <CAMYpm87L17V5bOhHbQKKQ=QMbhv8t_x4+D252F=2gCY8GrwLpQ@mail.gmail.com>
 <20160801010846.GA15571@mercury.ccil.org>
Message-ID: <CAMYpm870Yve6CSe14we2gx4zCyz+yJ2Q7=RpWnegM+WKXrvTuw@mail.gmail.com>

My 'incident' was around 1985 if I remember correctly. A time people
and border guards started to realise the possible value of what was on
such funny things like diskettes. Also I crossed 'National' borders.
Now that can be tricky even today :-)


On 01/08/2016, John Cowan <cowan at mercury.ccil.org> wrote:
>
> I carried an RK05 disk full of proprietary software from West Orange NJ
> to a client in Kansas City back in 1977.  Airport security existed, but
> it wasn't as anal it is today.  So when I told them they couldn't X-ray
> the disk, it might scramble it, they wanted to do a physical inspection --
> but I told them if they opened the disk they'd get dust in it and ruin it.
> Finally they took my word for it.
>
> When the disk got to the client's, it was completely scrambled anyway.
> I went back home, and next week my partner went out with a stack of 5.25s.
> It took him twenty hours to set up the client's system (I don't remember
> if it was a PDP-8 or a PDP-11), but the job got done.
>


From dot at dotat.at  Mon Aug  1 21:36:35 2016
From: dot at dotat.at (Tony Finch)
Date: Mon, 1 Aug 2016 12:36:35 +0100
Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp)
In-Reply-To: <AE8CA14F-7551-4618-80C7-835832DBD4B1@cheswick.com>
References: <579959F6.3050803@gmail.com>
 <20160728112330.GP3375@yeono.kjorling.se>
 <20160728135739.GA14303@mercury.ccil.org>
 <20160730075641.GT78278@eureka.lemis.com>
 <AE8CA14F-7551-4618-80C7-835832DBD4B1@cheswick.com>
Message-ID: <alpine.DEB.2.11.1608011234540.14894@grey.csi.cam.ac.uk>

William Cheswick <ches at cheswick.com> wrote:
>
> I was astonished to learn that one of those pinky-sized micro-SD cards
> has 33 circuit boards in it, stacked in a staggered formation.  32 have
> memory, one a fairly powerful CPU.

I don't think they have what I would call a circuit board inside: the
microSD card is itself a multi-chip package.

http://www.bunniestudios.com/blog/?page_id=1022

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Trafalgar: North or northwest 4 or 5, increasing 6 at times. Slight or
moderate. Fair. Good.


From scj at yaccman.com  Tue Aug  2 03:11:26 2016
From: scj at yaccman.com (scj at yaccman.com)
Date: Mon, 1 Aug 2016 10:11:26 -0700
Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp)
In-Reply-To: <CAMYpm870Yve6CSe14we2gx4zCyz+yJ2Q7=RpWnegM+WKXrvTuw@mail.gmail.com>
References: <CAMYpm87L17V5bOhHbQKKQ=QMbhv8t_x4+D252F=2gCY8GrwLpQ@mail.gmail.com>
 <20160801010846.GA15571@mercury.ccil.org>
 <CAMYpm870Yve6CSe14we2gx4zCyz+yJ2Q7=RpWnegM+WKXrvTuw@mail.gmail.com>
Message-ID: <1045a647a2347adfa400213707d00e8f.squirrel@webmail.yaccman.com>

> My 'incident' was around 1985 if I remember correctly. A time people
> and border guards started to realise the possible value of what was on
> such funny things like diskettes. Also I crossed 'National' borders.
> Now that can be tricky even today :-)
>
A Canadian friend of mine, after working in the US for five or so years,
was returning to Canada about 1969 with five years of research in 20 or 30
boxes of punched cards in the back of his car.  He was stopped at the
border and told that he would have to pay duty on the card boxes -- I
think the total came to over $200.  He argued with them for some time, and
finally one of the agents opened one of the boxes and said "Oh!  These are
USED punch cards!  There is no duty."



From clemc at ccc.com  Tue Aug  2 04:32:56 2016
From: clemc at ccc.com (Clem Cole)
Date: Mon, 1 Aug 2016 14:32:56 -0400
Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp)
In-Reply-To: <1045a647a2347adfa400213707d00e8f.squirrel@webmail.yaccman.com>
References: <CAMYpm87L17V5bOhHbQKKQ=QMbhv8t_x4+D252F=2gCY8GrwLpQ@mail.gmail.com>
 <20160801010846.GA15571@mercury.ccil.org>
 <CAMYpm870Yve6CSe14we2gx4zCyz+yJ2Q7=RpWnegM+WKXrvTuw@mail.gmail.com>
 <1045a647a2347adfa400213707d00e8f.squirrel@webmail.yaccman.com>
Message-ID: <CAC20D2P-Fu95P82Y5+SLHLYe7uOFD3OZ_9AZV2WECjUuh8qZYw@mail.gmail.com>

On Mon, Aug 1, 2016 at 1:11 PM, <scj at yaccman.com> wrote:

>  "Oh!  These are
> ​ ​
> USED punch cards!  There is no duty."
>
>
​For a long time, Canada was trying to tax software going over the border,
as well as some equipment.   When Kelly Booth was at Waterloo, he had 5
1/2" tapes with special stamps from the Canadian Gov he had to use to carry
things after having had tapes confiscated.   The funny part was you could
physically mail the tape, but if you tried to bring them personally; it was
an issue.   Kelly told me if they have been unopened and new it would not
have been an issue - but it was that it they were used that tended cause
issues.

I also remember getting a system ready for the Toronto USENIX.   It was
amazing the paper we needed, and had to prove we were not going to sell the
system there etc.

Clem

Clem

The problem was putting a value on things.   So they were marked as
research data IIRC, which
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160801/c1e54ad0/attachment.html>

From dave at horsfall.org  Wed Aug  3 08:38:58 2016
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 3 Aug 2016 08:38:58 +1000 (EST)
Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp)
In-Reply-To: <1045a647a2347adfa400213707d00e8f.squirrel@webmail.yaccman.com>
References: <CAMYpm87L17V5bOhHbQKKQ=QMbhv8t_x4+D252F=2gCY8GrwLpQ@mail.gmail.com>
 <20160801010846.GA15571@mercury.ccil.org>
 <CAMYpm870Yve6CSe14we2gx4zCyz+yJ2Q7=RpWnegM+WKXrvTuw@mail.gmail.com>
 <1045a647a2347adfa400213707d00e8f.squirrel@webmail.yaccman.com>
Message-ID: <alpine.BSF.2.11.1608030836530.10098@aneurin.horsfall.org>

On Mon, 1 Aug 2016, scj at yaccman.com wrote:

> A Canadian friend of mine, after working in the US for five or so years,
> was returning to Canada about 1969 with five years of research in 20 or 30
> boxes of punched cards in the back of his car.  He was stopped at the
> border and told that he would have to pay duty on the card boxes -- I
> think the total came to over $200.  He argued with them for some time, and
> finally one of the agents opened one of the boxes and said "Oh!  These are
> USED punch cards!  There is no duty."

Not Henry Spencer, perchance?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From norman at oclsc.org  Wed Aug  3 21:53:03 2016
From: norman at oclsc.org (Norman Wilson)
Date: Wed, 03 Aug 2016 07:53:03 -0400
Subject: [TUHS] History repeating itself (was: Unix v6 problem with /tmp)
Message-ID: <1470225188.15544.for-standards-violators@oclsc.org>

Dave Horsfall:

  Not Henry Spencer, perchance?

=====

Since the Canadian in question had been working in the US since
1964 or so, he must by now be pushing 70 years old.

I haven't seen Henry for some years, but I don't think he has
aged that much.

Norman Wilson
Toronto ON


From random832 at fastmail.com  Sun Aug 14 13:37:03 2016
From: random832 at fastmail.com (Random832)
Date: Sat, 13 Aug 2016 23:37:03 -0400
Subject: [TUHS] Help with a Unix-ish project?
In-Reply-To: <20160716014449.GA9414@minnie.tuhs.org>
References: <20160715225617.GB30146@minnie.tuhs.org>
 <1468632762.1363402.667765737.350D807F@webmail.messagingengine.com>
 <20160716014449.GA9414@minnie.tuhs.org>
Message-ID: <1471145823.1118263.694671257.09B04CBD@webmail.messagingengine.com>

On Fri, Jul 15, 2016, at 21:44, Warren Toomey wrote:
> I don't want to use this list as the discussion area for the project.
> I'll set another one up and we can move the conversation there.

Did this ever materialize?


From wkt at tuhs.org  Mon Aug 15 10:11:40 2016
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 15 Aug 2016 10:11:40 +1000
Subject: [TUHS] fstat(2) on pipes?
Message-ID: <20160815001140.GA16138@minnie.tuhs.org>

All, sorry this is slightly off-topic. I'm trying to
find out what fstat(2) returns when the file descriptor
is a pipe. The POSIX/Open Group documentation doesn't
really specify what should be returned. Does anybody have
any pointers?

Thanks, Warren

P.S. Why? xv6 has fstat() but returns an error if the
file descriptor isn't associated with an i-node. I'm
trying to work out if/how to fix it.


From dave at horsfall.org  Mon Aug 15 10:41:02 2016
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 15 Aug 2016 10:41:02 +1000 (EST)
Subject: [TUHS] fstat(2) on pipes?
In-Reply-To: <20160815001140.GA16138@minnie.tuhs.org>
References: <20160815001140.GA16138@minnie.tuhs.org>
Message-ID: <alpine.BSF.2.11.1608151037130.10703@aneurin.horsfall.org>

On Mon, 15 Aug 2016, Warren Toomey wrote:

> All, sorry this is slightly off-topic. I'm trying to find out what 
> fstat(2) returns when the file descriptor is a pipe. The POSIX/Open 
> Group documentation doesn't really specify what should be returned. Does 
> anybody have any pointers?

I always thought it was undefined, but my Mac says:

BUGS
     Applying fstat to a socket (and thus to a pipe) returns a zero'd buffer,
     except for the blocksize field, and a unique device and inode number.

And my FreeBSD box is the same; I haven't checked my Penguins.

> P.S. Why? xv6 has fstat() but returns an error if the file descriptor 
> isn't associated with an i-node. I'm trying to work out if/how to fix 
> it.

Probably not much use to you, but back in Ed6 I did modify it to return
the amount of data in the pipe.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."


From jnc at mercury.lcs.mit.edu  Mon Aug 15 10:27:11 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Sun, 14 Aug 2016 20:27:11 -0400 (EDT)
Subject: [TUHS] fstat(2) on pipes?
Message-ID: <20160815002711.3F3C418C096@mercury.lcs.mit.edu>

    > From: Warren Toomey

    > I'm trying to find out what fstat(2) returns when the file descriptor
    > is a pipe.

In V6, it returns information about the file (inode) used as a temporary
storage area for data which has been written into the pipe, but not yet read;
i.e. it's an un-named file with a length which varies between 0 and 4KB.

    > xv6 has fstat() but returns an error if the file descriptor isn't
    > associated with an i-node.

?? All pipe file descriptors should have an inode?

	Noel


From wkt at tuhs.org  Mon Aug 15 10:54:52 2016
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 15 Aug 2016 10:54:52 +1000
Subject: [TUHS] fstat(2) on pipes?
In-Reply-To: <alpine.BSF.2.11.1608151037130.10703@aneurin.horsfall.org>
References: <20160815001140.GA16138@minnie.tuhs.org>
 <alpine.BSF.2.11.1608151037130.10703@aneurin.horsfall.org>
Message-ID: <20160815005452.GA21951@minnie.tuhs.org>

On Mon, Aug 15, 2016 at 10:41:02AM +1000, Dave Horsfall wrote:
> Probably not much use to you, but back in Ed6 I did modify it to return
> the amount of data in the pipe.

7th Ed seems to return the amount of free space in the pipe, if I read
the code correctly:

fstat()
{
   ...
   /* Call stat1() with the current offset in the pipe */
   stat1(fp->f_inode, uap->sb, fp->f_flag&FPIPE? fp->f_un.f_offset: 0);
}

stat1()
{
   ...
   ds.st_size = ip->i_size - pipeadj;
}

Cheers, Warren


From wkt at tuhs.org  Mon Aug 15 10:59:04 2016
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 15 Aug 2016 10:59:04 +1000
Subject: [TUHS] fstat(2) on pipes?
In-Reply-To: <20160815002711.3F3C418C096@mercury.lcs.mit.edu>
References: <20160815002711.3F3C418C096@mercury.lcs.mit.edu>
Message-ID: <20160815005904.GB21951@minnie.tuhs.org>

Warren wrote:
>     > xv6 has fstat() but returns an error if the file descriptor isn't
>     > associated with an i-node.
 
On Sun, Aug 14, 2016 at 08:27:11PM -0400, Noel Chiappa wrote:
> ?? All pipe file descriptors should have an inode?

xv6 is a Unix-like OS written for teaching purposes. I'm
making changes to give it a decent runtime environment. URLs:

https://pdos.csail.mit.edu/6.828/2014/xv6.html
https://github.com/DoctorWkt/xv6-freebsd

and it comes with it's own Lions-style commentary:
https://pdos.csail.mit.edu/6.828/2014/xv6/book-rev8.pdf

Cheers, Warren


From jnc at mercury.lcs.mit.edu  Tue Aug 16 00:04:50 2016
From: jnc at mercury.lcs.mit.edu (Noel Chiappa)
Date: Mon, 15 Aug 2016 10:04:50 -0400 (EDT)
Subject: [TUHS] fstat(2) on pipes?
Message-ID: <20160815140450.C6CC618C0B3@mercury.lcs.mit.edu>

    > From: Warren Toomey

    > xv6 is a Unix-like OS written for teaching purposes. 

I'm fairly well-aware of Xv6; I too am planning to use it in a project.

But back to the original topic, it sounds like there's a huge amount of
variance in the semantics of doing fstat() on a pipe. V6 doesn't special-case
it in any way, but it sounds as if other systems do.

What V6 does (to complete the list) is grow the temporary file being used to
buffer the pipe contents up to a certain maximum size, whereupon it halts the
writer, and waits for the reader to catch up - at which point it truncates
the file, and adjusts the read and write pointers back to 0. So fstat() on
V6, which doesn't special-case pipes in any way for fstat(), apparently
returns 'waiting_to_be_read' plus 'already_read'.


    >>> xv6 has fstat() but returns an error if the file descriptor isn't
    >>> associated with an i-node.

    >> ?? All pipe file descriptors should have an inode?

To answer my own question, after a quick look at the Xv6 sources (on my
desktop ;-); it turns out that Xv6 handles pipes completely differently;
instead of borrowing an inode, they have special 'pipe' structures.  Hence the
error return in fstat() on Xv6. (That difference also limits the amount of
buffered data in a pipe to 512 bytes. So don't expect high throughput from a
pipe on Xv6! :-)

So I guess you get to pick which semantics you want fstat() on a pipe to have
there: V6's, V7's (see below), or something else! :-)


    > 7th Ed seems to return the amount of free space in the pipe, if I read
    > the code correctly:

I'm not sure of that (see below), but I think it would make more sense to
return the amount of un-read data (which is what I think it does do), as the
closest semantics to fstat() on a file.

It might also make sense to return the amount of free space (to a writer), and
the amount of data available to read (to a reader), since those are the
numbers users will care about. (Although then fstat() on the write side of a
pipe will have semantics which are inconsistent with fstat() on files. And if
the user code knows the maximum amount of buffering in a pipe, it could work
out the available write space from that, and the amount currently un-read.)

    > fstat()
    > {
    >    ...
    >    /* Call stat1() with the current offset in the pipe */
    >   stat1(fp->f_inode, uap->sb, fp->f_flag&FPIPE? fp->f_un.f_offset: 0);
    > }
    > stat1()
    > {
    >   ...
    >    ds.st_size = ip->i_size - pipeadj;

I'm too lazy to go read the code (even though I already have it :-), but V7
seems to usually be very similar to V6. So, what I suspect this code does is
pass the expression:

  ((fp->f_flag & FPIPE) ? fp->f_un.f_offset : 0)

as 'pipeadj' (to account for the amount that's already been read), and then
returns (ip->i_size - pipeadj), i.e. the amount remaining un-read, as the
size.

	Noel


From random832 at fastmail.com  Tue Aug 16 01:14:45 2016
From: random832 at fastmail.com (Random832)
Date: Mon, 15 Aug 2016 11:14:45 -0400
Subject: [TUHS] fstat(2) on pipes?
In-Reply-To: <20160815140450.C6CC618C0B3@mercury.lcs.mit.edu>
References: <20160815140450.C6CC618C0B3@mercury.lcs.mit.edu>
Message-ID: <1471274085.1099635.695741217.6472725F@webmail.messagingengine.com>

On Mon, Aug 15, 2016, at 10:04, Noel Chiappa wrote:
> But back to the original topic, it sounds like there's a huge amount
> of variance in the semantics of doing fstat() on a pipe. V6 doesn't
> special-case it in any way, but it sounds as if other systems do.

I expect that the single important thing, the only thing that most
applications will rely on, is it returning successfully and indicating
that the file type is fifo. If your version of xv6 supports file
permissions and if pipes are one-way it may be worthwhile to indicate
which end of the pipe it is.

In the standard: the use of the size field is explicitly unspecified for
pipes - for any file type other than regular files, symbolic links, and
shared/typed memory objects. Other than that, it's clear from the
standard that it's intended to succeed and report a sensible file type
for non-filesystem objects like pipes, shared memory objects, and
sockets. However, there's no discussion of what, if anything, belongs in
the dev/inode*, permissions, nlink, and timestamps.

On Linux: st_dev is a device number specific to pipes and st_ino is a
unique inode number. I haven't tested the timestamps thoroughly (my test
only covered instantaneously opening and statting a pipe), but they are
valid timestamps rather than being 0 or -1 or some garbage value.
st_uid/gid are [probably, haven't tested complicated cases] the user
that created it, st_nlink is 1, and the permissions are set to
[user-only] the read or write mode the pipe is opened in.

*Though, the standard's light on the meaning of device identifiers in
the first place, and what it does say could easily be read as demanding
a unique device/inode pair regardless of the nonexistence of a physical
device, which naturally leads to the solution that I observed on Linux
and that someone else mentioned on OSX.


From michael at kjorling.se  Tue Aug 16 02:56:45 2016
From: michael at kjorling.se (Michael =?utf-8?B?S2rDtnJsaW5n?=)
Date: Mon, 15 Aug 2016 16:56:45 +0000
Subject: [TUHS] fstat(2) on pipes?
In-Reply-To: <1471274085.1099635.695741217.6472725F@webmail.messagingengine.com>
References: <20160815140450.C6CC618C0B3@mercury.lcs.mit.edu>
 <1471274085.1099635.695741217.6472725F@webmail.messagingengine.com>
Message-ID: <20160815165645.GE655@yeono.kjorling.se>

On 15 Aug 2016 11:14 -0400, from random832 at fastmail.com (Random832):
> On Mon, Aug 15, 2016, at 10:04, Noel Chiappa wrote:
>> But back to the original topic, it sounds like there's a huge amount
>> of variance in the semantics of doing fstat() on a pipe. V6 doesn't
>> special-case it in any way, but it sounds as if other systems do.
> 
> I expect that the single important thing, the only thing that most
> applications will rely on, is it returning successfully and indicating
> that the file type is fifo.

On Linux/glibc, based on the fstat(2) man page, it looks like the size
field is undefined for a FIFO:

> The st_size field gives the size of the file (if it is a regular
> file or a symbolic link) in bytes. The size of a symbolic link is
> the length of the pathname it contains, without a terminating null
> byte.

The mode field is used to hold the type of file:

> The following POSIX macros are defined to check the file type using
> the st_mode field:
> 
> ...
>     S_ISFIFO(m) FIFO (named pipe)?
> ...
> 
> The following flags are defined for the st_mode field:
> ...
>     S_IFIFO    0010000   FIFO
> ...

The above from Debian Wheezy.

-- 
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)


From norman at oclsc.org  Tue Aug 16 03:47:03 2016
From: norman at oclsc.org (Norman Wilson)
Date: Mon, 15 Aug 2016 13:47:03 -0400
Subject: [TUHS] fstat(2) on pipes?
Message-ID: <1471283229.3510.for-standards-violators@oclsc.org>

I remember once, long ago--probably in the early 1980s--writing
a program that expected fstat on a pipe to return the amount of
data buffered in the pipe.  It worked on the system on which
I wrote the code.  Then I tried it on another, related but
different UNIX, and it didn't work.  So if POSIX/SUS don't
prescribe a standard, I don't think one should pretend there
is one, and (as I learned back then) it's unwise to depend
on the result, except I think it's fair not to expect fstat
to fail on any valid file descriptor.

I'm pretty sure that in 7/e and earlier, fstat on a pipe
reported a regular file with zero links.  There was a reason
for this: the kernel in fact allocated an i-node from a
designated pipe device (pipedev) file system, usually the
root.  So the excuse that `there's no i-node' was just wrong.

In last-generation Research systems, when pipes were streams
(and en passant became full duplex, which caused no trouble
at all but simplified life elsewhere--I think I was the one
who realized that meant we didn't need pseudo-ttys any more),
the system allocated a pair of in-core i-nodes when a pipe
was created.  As long as such an i-node cannot be accidentally
confused with one belonging to any disk file system, this
causes no trouble at all, and since it is possible to have
more than one disk file system this is trivially possible
just by reserving a device number.  (In fact by then our
in-core i-nodes were marked with a file system type as well,
and pipes just became their own file system.)  stat always
returned size 0 for (Research) stream pipes, partly because
nobody cared enough, partly because the implementation of
streams didn't keep an exact count of all the buffered data
all along the stream, just a rough one sufficient for flow
control.  Besides, with a full-duplex pipe, which direction's
data should be counted?

Returning to the original question, I'd suggest that:
-- fstat(fd) where fd is a pipe should succeed
-- the file should be reported to have zero links,
since that is the case for a pipe (unless a named pipe,
but if you support those you probably have something
else to stat anyway)
-- the file type should be IFIFO if that type exists
in xv6 (which it wouldn't were it a real emulation of
6/e, but I gather that's not the goal), IFREG otherwise
-- permissions probably don't matter much, but for
sanity's sake should be some reasonable constant.

Norman Wilson
Toronto ON


From clemc at ccc.com  Tue Aug 16 03:53:28 2016
From: clemc at ccc.com (Clem Cole)
Date: Mon, 15 Aug 2016 13:53:28 -0400
Subject: [TUHS] fstat(2) on pipes?
In-Reply-To: <20160815001140.GA16138@minnie.tuhs.org>
References: <20160815001140.GA16138@minnie.tuhs.org>
Message-ID: <CAC20D2PcxqfWzEsKc_Z3TKptOQFsorD2sUfKSXd2=_ccNz_fBg@mail.gmail.com>

​Yet Another Example of UNIX A != UNIX B​

IIRC from the /usr/group and later POSIX discussions, the only thing that
is for sure on the stat structure with a PIPE is that it's marked as such.

That said, I just grabbed my copy of the SVID (Vol 1 pages 126-127)

st_size "For ordinary files, this field is the address of the end of file.
  For pipes and FIFO's, this field is the count of the data currently in
the file.   For block-special & char special, this field is undefined."

As for st_ino and st_dev -- the SVID says the ino "uniquely identifies the
file in a given file system," and dev uniquely identifies the file system
that contains the file."

It further states: "The pair of fields st_ino and st_dev uniquely
identifies ordinary files."     And then later says "No other significance
is associated with this value."


So..... clearly returning an error is wrong.   I don't think the Linux
scheme hurts anything....


On Sun, Aug 14, 2016 at 8:11 PM, Warren Toomey <wkt at tuhs.org> wrote:

> All, sorry this is slightly off-topic. I'm trying to
> find out what fstat(2) returns when the file descriptor
> is a pipe. The POSIX/Open Group documentation doesn't
> really specify what should be returned. Does anybody have
> any pointers?
>
> Thanks, Warren
>
> P.S. Why? xv6 has fstat() but returns an error if the
> file descriptor isn't associated with an i-node. I'm
> trying to work out if/how to fix it.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160815/e8a2a75e/attachment.html>

From dave at horsfall.org  Mon Aug 29 04:21:46 2016
From: dave at horsfall.org (Dave Horsfall)
Date: Mon, 29 Aug 2016 04:21:46 +1000 (EST)
Subject: [TUHS] Comments on "C"
Message-ID: <alpine.BSF.2.11.1608290416020.74486@aneurin.horsfall.org>

Seen on another list...  And I got quoted by Steve Bellovin :-)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

---------- Forwarded message ----------
From: Kent Borg
To: cryptography at metzdowd.com
Subject: Re: [Cryptography]
    "NSA-linked Cisco exploit poses bigger threat than previously thought"

On 08/25/2016 06:06 PM, Steven M. Bellovin wrote:

> I first heard more or less that line from Doug McIlroy himself; he 
> called C the best assembler language he'd ever used.

Ancient fun-fact: Years ago there was an article in Byte magazine 
describing how a useful subset of C could be directly assembled into 68000 
code. Not compiled, assembled.

C is a stunning assembly language. When those wild-eyed nerds at AT&T 
decided to write Unix not in assembly but in C (where was management!?), 
it was radical. But C was up to (down to?) the task, it was pioneering 
then and is still doing useful things decades later: From the fastest 
supercomputers to some pretty slim microcontrollers (plus a hell of a lot 
of Android devices) multitudes of computers run a Linux kernel compiled 
from the *same* C source code, with almost no assembly. Big-endian, 
little-endian: no matter. Different word lengths: no matter.

That is one impressive cross-platform assembly language!

Unfortunately, C is also a dangerous language that mortal programmers 
cannot reliably wield.

-kb, the Kent who knows he is pressing his luck on a moderated 
cryptography mailing list, but C deserves a lot of respect, as it also 
deserves to be efficiently sent into a dignified retirement.

_______________________________________________
The cryptography mailing list
cryptography at metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography



From rochkind at basepath.com  Mon Aug 29 10:37:21 2016
From: rochkind at basepath.com (Marc Rochkind)
Date: Sun, 28 Aug 2016 18:37:21 -0600
Subject: [TUHS] Comments on "C"
In-Reply-To: <alpine.BSF.2.11.1608290416020.74486@aneurin.horsfall.org>
References: <alpine.BSF.2.11.1608290416020.74486@aneurin.horsfall.org>
Message-ID: <CAOkr1zXkmRx7p1sET=a+1ffh=nSeh0G-vTDipiZPAjTbVVYQ_Q@mail.gmail.com>

Yeah, OK, another one of those clever glib UNIXy aphorisms.

But, as anyone who's actually programmed seriously in assembly language
knows, C is not assembler. It is a system programming language low enough
to be used for things that were once done in assembler, the most important
of which is an OS.

So, for most of us, we no longer had to write in assembler. But that
doesn't mean C is assembler.

So, are we just having fun over a few beers, or talking seriously? I like
both!

--Marc Rochkind

On Sun, Aug 28, 2016 at 12:21 PM, Dave Horsfall <dave at horsfall.org> wrote:

> Seen on another list...  And I got quoted by Steve Bellovin :-)
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
> ---------- Forwarded message ----------
> From: Kent Borg
> To: cryptography at metzdowd.com
> Subject: Re: [Cryptography]
>     "NSA-linked Cisco exploit poses bigger threat than previously thought"
>
> On 08/25/2016 06:06 PM, Steven M. Bellovin wrote:
>
> > I first heard more or less that line from Doug McIlroy himself; he
> > called C the best assembler language he'd ever used.
>
> Ancient fun-fact: Years ago there was an article in Byte magazine
> describing how a useful subset of C could be directly assembled into 68000
> code. Not compiled, assembled.
>
> C is a stunning assembly language. When those wild-eyed nerds at AT&T
> decided to write Unix not in assembly but in C (where was management!?),
> it was radical. But C was up to (down to?) the task, it was pioneering
> then and is still doing useful things decades later: From the fastest
> supercomputers to some pretty slim microcontrollers (plus a hell of a lot
> of Android devices) multitudes of computers run a Linux kernel compiled
> from the *same* C source code, with almost no assembly. Big-endian,
> little-endian: no matter. Different word lengths: no matter.
>
> That is one impressive cross-platform assembly language!
>
> Unfortunately, C is also a dangerous language that mortal programmers
> cannot reliably wield.
>
> -kb, the Kent who knows he is pressing his luck on a moderated
> cryptography mailing list, but C deserves a lot of respect, as it also
> deserves to be efficiently sent into a dignified retirement.
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160828/076f3852/attachment.html>

From lm at mcvoy.com  Mon Aug 29 10:42:37 2016
From: lm at mcvoy.com (Larry McVoy)
Date: Sun, 28 Aug 2016 17:42:37 -0700
Subject: [TUHS] Comments on "C"
In-Reply-To: <CAOkr1zXkmRx7p1sET=a+1ffh=nSeh0G-vTDipiZPAjTbVVYQ_Q@mail.gmail.com>
References: <alpine.BSF.2.11.1608290416020.74486@aneurin.horsfall.org>
 <CAOkr1zXkmRx7p1sET=a+1ffh=nSeh0G-vTDipiZPAjTbVVYQ_Q@mail.gmail.com>
Message-ID: <20160829004237.GC14366@mcvoy.com>

I'm with Marc.  I think the C syntax is really pleasant, and while I enjoyed
writing PDP-11 assembler (by far my favorite out the ones I've done which
include VAX, m68k, 32032, z80, sparc, some x86 but not much), I don't want
go back to writing assembler unless I have to.  C is a pleasant language
that easily compiles to assembler.

I happen to like it so much I made a scripting language that looks very 
C like, with some perl pleasantness tossed in (without all the dollar
signs).  Check it out at

http://www.little-lang.org

100% open source, actively developed, yada, yada.

On Sun, Aug 28, 2016 at 06:37:21PM -0600, Marc Rochkind wrote:
> Yeah, OK, another one of those clever glib UNIXy aphorisms.
> 
> But, as anyone who's actually programmed seriously in assembly language
> knows, C is not assembler. It is a system programming language low enough
> to be used for things that were once done in assembler, the most important
> of which is an OS.
> 
> So, for most of us, we no longer had to write in assembler. But that
> doesn't mean C is assembler.
> 
> So, are we just having fun over a few beers, or talking seriously? I like
> both!
> 
> --Marc Rochkind
> 
> On Sun, Aug 28, 2016 at 12:21 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> > Seen on another list...  And I got quoted by Steve Bellovin :-)
> >
> > --
> > Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> > suffer."
> >
> > ---------- Forwarded message ----------
> > From: Kent Borg
> > To: cryptography at metzdowd.com
> > Subject: Re: [Cryptography]
> >     "NSA-linked Cisco exploit poses bigger threat than previously thought"
> >
> > On 08/25/2016 06:06 PM, Steven M. Bellovin wrote:
> >
> > > I first heard more or less that line from Doug McIlroy himself; he
> > > called C the best assembler language he'd ever used.
> >
> > Ancient fun-fact: Years ago there was an article in Byte magazine
> > describing how a useful subset of C could be directly assembled into 68000
> > code. Not compiled, assembled.
> >
> > C is a stunning assembly language. When those wild-eyed nerds at AT&T
> > decided to write Unix not in assembly but in C (where was management!?),
> > it was radical. But C was up to (down to?) the task, it was pioneering
> > then and is still doing useful things decades later: From the fastest
> > supercomputers to some pretty slim microcontrollers (plus a hell of a lot
> > of Android devices) multitudes of computers run a Linux kernel compiled
> > from the *same* C source code, with almost no assembly. Big-endian,
> > little-endian: no matter. Different word lengths: no matter.
> >
> > That is one impressive cross-platform assembly language!
> >
> > Unfortunately, C is also a dangerous language that mortal programmers
> > cannot reliably wield.
> >
> > -kb, the Kent who knows he is pressing his luck on a moderated
> > cryptography mailing list, but C deserves a lot of respect, as it also
> > deserves to be efficiently sent into a dignified retirement.
> >
> > _______________________________________________
> > The cryptography mailing list
> > cryptography at metzdowd.com
> > http://www.metzdowd.com/mailman/listinfo/cryptography
> >
> >

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 


From usotsuki at buric.co  Mon Aug 29 11:54:43 2016
From: usotsuki at buric.co (Steve Nickolas)
Date: Sun, 28 Aug 2016 21:54:43 -0400 (EDT)
Subject: [TUHS] Comments on "C"
In-Reply-To: <20160829004237.GC14366@mcvoy.com>
References: <alpine.BSF.2.11.1608290416020.74486@aneurin.horsfall.org>
 <CAOkr1zXkmRx7p1sET=a+1ffh=nSeh0G-vTDipiZPAjTbVVYQ_Q@mail.gmail.com>
 <20160829004237.GC14366@mcvoy.com>
Message-ID: <alpine.BSF.2.02.1608282153280.14733@frieza.hoshinet.org>

On Sun, 28 Aug 2016, Larry McVoy wrote:

> I'm with Marc.  I think the C syntax is really pleasant, and while I enjoyed
> writing PDP-11 assembler (by far my favorite out the ones I've done which
> include VAX, m68k, 32032, z80, sparc, some x86 but not much), I don't want
> go back to writing assembler unless I have to.  C is a pleasant language
> that easily compiles to assembler.

Yeah, C's a really nice language.  About as high as Pascal and at the same 
time almost as low as ASM.

It's just a pity it's a horrible fit on the 6502 (my usual CPU of choice).

-uso.


From grog at lemis.com  Mon Aug 29 13:16:19 2016
From: grog at lemis.com (Greg 'groggy' Lehey)
Date: Mon, 29 Aug 2016 13:16:19 +1000
Subject: [TUHS] Comments on "C"
In-Reply-To: <CAOkr1zXkmRx7p1sET=a+1ffh=nSeh0G-vTDipiZPAjTbVVYQ_Q@mail.gmail.com>
References: <alpine.BSF.2.11.1608290416020.74486@aneurin.horsfall.org>
 <CAOkr1zXkmRx7p1sET=a+1ffh=nSeh0G-vTDipiZPAjTbVVYQ_Q@mail.gmail.com>
Message-ID: <20160829031619.GB48170@eureka.lemis.com>

On Sunday, 28 August 2016 at 18:37:21 -0600, Marc Rochkind wrote:
> Yeah, OK, another one of those clever glib UNIXy aphorisms.
>
> But, as anyone who's actually programmed seriously in assembly language
> knows, C is not assembler. It is a system programming language low enough
> to be used for things that were once done in assembler, the most important
> of which is an OS.

Agreed, calling assembler is being deliberately a little silly.  But
there is a connection: when I write C, I can envision what code is
going to be produced.  With many languages, including C++, you can't
be so sure.

"A LISP programmer knows the value of everything and the cost of
nothing".

> So, are we just having fun over a few beers, or talking seriously? I
> like both!

I'll go for the beer.

Greg
--
Sent from my desktop computer.
Finger grog at FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160829/22dc6a9a/attachment.sig>

From beebe at math.utah.edu  Tue Aug 30 10:22:11 2016
From: beebe at math.utah.edu (Nelson H. F. Beebe)
Date: Mon, 29 Aug 2016 18:22:11 -0600
Subject: [TUHS] [tuhs] the origins of fork and join
Message-ID: <CMM.0.96.0.1472516531.beebe@gamma.math.utah.edu>

The latest issue of the IEEE Annals of Computing was published
electronically today, and it has an article that I expect many
TUHS list readers will enjoy reading:

	Notes on the History of Fork and Join
	http://dx.doi.org/10.1109/MAHC.2016.34

-------------------------------------------------------------------------------
- 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 at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------


From rochkind at basepath.com  Tue Aug 30 12:52:08 2016
From: rochkind at basepath.com (Marc Rochkind)
Date: Mon, 29 Aug 2016 20:52:08 -0600
Subject: [TUHS] [tuhs] the origins of fork and join
In-Reply-To: <CMM.0.96.0.1472516531.beebe@gamma.math.utah.edu>
References: <CMM.0.96.0.1472516531.beebe@gamma.math.utah.edu>
Message-ID: <CAOkr1zUVXpxxBoo8VhUf9ctB-qSWsjqDGD=tsE7rt1J5HfoCuw@mail.gmail.com>

Thanks! Nice to be reminded that there was a time when everything had to be
figured out. Even now, of course.

On Monday, August 29, 2016, Nelson H. F. Beebe <beebe at math.utah.edu> wrote:

> The latest issue of the IEEE Annals of Computing was published
> electronically today, and it has an article that I expect many
> TUHS list readers will enjoy reading:
>
>         Notes on the History of Fork and Join
>         http://dx.doi.org/10.1109/MAHC.2016.34
>
> ------------------------------------------------------------
> -------------------
> - 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 at math.utah.edu <javascript:;>  -
> - 155 S 1400 E RM 233                       beebe at acm.org <javascript:;>
> beebe at computer.org <javascript:;> -
> - Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~
> beebe/ -
> ------------------------------------------------------------
> -------------------
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160829/bd133068/attachment.html>

From tfb at tfeb.org  Wed Aug 31 20:02:28 2016
From: tfb at tfeb.org (Tim Bradshaw)
Date: Wed, 31 Aug 2016 11:02:28 +0100
Subject: [TUHS] Comments on "C"
In-Reply-To: <20160829031619.GB48170@eureka.lemis.com>
References: <alpine.BSF.2.11.1608290416020.74486@aneurin.horsfall.org>
 <CAOkr1zXkmRx7p1sET=a+1ffh=nSeh0G-vTDipiZPAjTbVVYQ_Q@mail.gmail.com>
 <20160829031619.GB48170@eureka.lemis.com>
Message-ID: <15EAA199-2C57-4621-A71E-95E046086BB5@tfeb.org>


On 29 Aug 2016, at 04:16, Greg 'groggy' Lehey <grog at lemis.com> wrote:

> "A LISP programmer knows the value of everything and the cost of
> nothing".

A C programmer knows the cost of all sufficiently simple things and the value of nothing. No significant programs written since 1980 have been sufficiently simple.

(This isn't meant as a hostile comment!)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160831/a7f582b2/attachment.sig>

From cowan at ccil.org  Wed Aug 31 22:59:32 2016
From: cowan at ccil.org (John Cowan)
Date: Wed, 31 Aug 2016 08:59:32 -0400
Subject: [TUHS] Comments on "C"
In-Reply-To: <15EAA199-2C57-4621-A71E-95E046086BB5@tfeb.org>
References: <alpine.BSF.2.11.1608290416020.74486@aneurin.horsfall.org>
 <CAOkr1zXkmRx7p1sET=a+1ffh=nSeh0G-vTDipiZPAjTbVVYQ_Q@mail.gmail.com>
 <20160829031619.GB48170@eureka.lemis.com>
 <15EAA199-2C57-4621-A71E-95E046086BB5@tfeb.org>
Message-ID: <CAD2gp_TdEBKDhvT80vFTT9jk3yY=3wjocNrG4Lhe646aDB0DxA@mail.gmail.com>

On Wed, Aug 31, 2016 at 6:02 AM, Tim Bradshaw <tfb at tfeb.org> wrote:

A C programmer knows the cost of all sufficiently simple things and the
> value of nothing


The value of nothing is 0, or on unusual architectures, (void *)0.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Today an interactive brochure website, tomorrow a global content
management system that leverages collective synergy to drive "outside of
the box" thinking and formulate key objectives into a win-win game plan
with a quality-driven approach that focuses on empowering key players
to drive-up their core competencies and increase expectations with an
all-around initiative to drive up the bottom-line. --Alex Papadimoulis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160831/fe96cb60/attachment.html>

From ron at ronnatalie.com  Wed Aug 31 23:32:10 2016
From: ron at ronnatalie.com (Ron Natalie)
Date: Wed, 31 Aug 2016 09:32:10 -0400
Subject: [TUHS] Comments on "C"
In-Reply-To: <CAD2gp_TdEBKDhvT80vFTT9jk3yY=3wjocNrG4Lhe646aDB0DxA@mail.gmail.com>
References: <alpine.BSF.2.11.1608290416020.74486@aneurin.horsfall.org>
 <CAOkr1zXkmRx7p1sET=a+1ffh=nSeh0G-vTDipiZPAjTbVVYQ_Q@mail.gmail.com>
 <20160829031619.GB48170@eureka.lemis.com>
 <15EAA199-2C57-4621-A71E-95E046086BB5@tfeb.org>
 <CAD2gp_TdEBKDhvT80vFTT9jk3yY=3wjocNrG4Lhe646aDB0DxA@mail.gmail.com>
Message-ID: <01a901d2038c$157e4ff0$407aefd0$@ronnatalie.com>

 


> The value of nothing is 0, or on unusual architectures, (void *)0.

 

T null pointer constant does not need a cast on ANY architecture .

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160831/36b083ea/attachment.html>

From brantleycoile at me.com  Wed Aug 31 23:57:45 2016
From: brantleycoile at me.com (Brantley Coile)
Date: Wed, 31 Aug 2016 09:57:45 -0400
Subject: [TUHS] Comments on "C"
In-Reply-To: <CAOkr1zXkmRx7p1sET=a+1ffh=nSeh0G-vTDipiZPAjTbVVYQ_Q@mail.gmail.com>
References: <alpine.BSF.2.11.1608290416020.74486@aneurin.horsfall.org>
 <CAOkr1zXkmRx7p1sET=a+1ffh=nSeh0G-vTDipiZPAjTbVVYQ_Q@mail.gmail.com>
Message-ID: <A93CB1E4-3643-4653-9A74-699BAAB3DEB9@me.com>


> On Aug 28, 2016, at 8:37 PM, Marc Rochkind <rochkind at basepath.com> wrote:
> 
> But, as anyone who's actually programmed seriously in assembly language knows, C is not assembler. It is a system programming language low enough to be used for things that were once done in assembler, the most important of which is an OS.
> 
> So, for most of us, we no longer had to write in assembler. But that doesn't mean C is assembler.
> 

Interestingly, assembler seems to be making a come back if one gives any credence to the Tiobe index. http://www.tiobe.com/tiobe-index/ As one who has written a lot of assembler code and no small number of assemblers, I wouldn’t like to write in assembler again. The problem is the lack of redundancy to catch errors.

As you all know (preaching to the choir here) the semantic model for C is the common von Neumann architecture. With the exceptions of returning structures, the semantics map one to one with most machines. This means that I can write C code and know pretty well what instructions are going to be generated. This in turn means that I can use C for almost all cases where I would have had to use assembler. The great Niklaus Wirth demonstrated this with his Oberon and some other small languages that completely replaced the use of assembler in his systems.

Some modern compliers have broken this, however. I have never been able to figure out what clang is going to do. But I should expect 28,000,000 bytes of instructions to do weird things. There’s no reason a C compiler should ever be more than about 0.25 MB of text.

  Brantley Coile



