I've been sitting on this question for years, hoping I'd come across the
answer, and I STILL don't know what the "i" is short for. Somebody here has
got to know this. :)
I know what an inode IS (although it took me almost a year to figure this
out, way back when), but I don't know what the name means.
I've been following this list for years now, and nobody's ever actually said
what the i stands for, and neither do the (sparse) comments in fs/inode.c.
I've read Peter Salus's book "a Quarter Century of Unix". I've read the
history of early unix development on Dennis Richie's home page, and although
it complains that his original notes came back form the dictation service
misspelling "inode" as "eyenode", it doesn't say what the I stands for. I'm
only about a third of the way into "Life with Unix", but it doesn't seem like
a particularly technical history so far...
Another question I'm unclear about is "does every userspace-visible memory
allocation have an inode"? Loaded programs are basically mmaped files, and
shared memory is now its own filesystem out of which you mmap stuff. But I
don't know about a process's stack and heap.
For a while I thought that swap could be thought of as a filesystem out of
which the heaps were mapped as sparse files (this is the only explanation
that made sense in early 2.5 when every page used HAD to have swap backing
store, and taking away the mandatory backing store would just be an exercise
in deferred allocation), but that apparently is not the case and I got
disabused of this notion a while back. Instead I learn what a "classzone"
is. Ok...
Then earlier today I wander across kerneltrap's interview with Larry McVoy,
who espouses the viewpoint that Linux VM design should store statistics in
inodes rather than worrying so much about individual pages, and I get
confused again.
Has each process space's heap got an inode? If so, in what filesystem?
Rob
(Yes, I am breaking the internet convention of posting errors rather than
asking questions if you want people to respond. I can come up with some
errors if you'd like. I'm good at that. :)
On Thursday 18 July 2002 05:33 pm, Rob Landley wrote:
> I've been sitting on this question for years, hoping I'd come
> across the answer, and I STILL don't know what the "i" is
> short for. Somebody here has got to know this. :)
"index," perhaps?
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
> I've been sitting on this question for years, hoping I'd come across the
> answer, and I STILL don't know what the "i" is short for. Somebody here has
> got to know this. :)
Incore node, I believe. In the original Unix code there was dinode and
inode if I remember correctly, for disk node and incore node.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
On Thu, Jul 18, 2002 at 09:38:57PM -0700, Larry McVoy wrote:
> On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
> > I've been sitting on this question for years, hoping I'd come
> > across the answer, and I STILL don't know what the "i" is short for.
> > Somebody here has got to know this. :)
>
> Incore node, I believe. In the original Unix code there was dinode and
> inode if I remember correctly, for disk node and incore node.
That's a new one. I always thought it was 'information node' so in the
above it'd be disk information node and just information node.
Makes sense to me in any case. :)
--
GOVERNMENT ANNOUNCEMENT - The government announced today that it is
changing its mascot to a condom because it more clearly reflects the
government's political stance. A condom stands up to inflation, halts
production, destroys the next generation, protects a bunch of pricks
and finally, gives you a sense of security while you're being screwed!
> I've been sitting on this question for years, hoping I'd come across the
> answer, and I STILL don't know what the "i" is short for. Somebody here has
> got to know this. :)
indirection
I think U should have referred
The Design of the Unix Operating Systems
-Maurice J Bach.
He tells that I stands for Index. ;-)
-MG
-----Original Message-----
From: Rob Landley [mailto:[email protected]]
Sent: Friday, July 19, 2002 4:04 AM
To: [email protected]
Subject: Alright, I give up. What does the "i" in "inode" stand for?
I've been sitting on this question for years, hoping I'd come across the
answer, and I STILL don't know what the "i" is short for. Somebody here has
got to know this. :)
I know what an inode IS (although it took me almost a year to figure this
out, way back when), but I don't know what the name means.
I've been following this list for years now, and nobody's ever actually said
what the i stands for, and neither do the (sparse) comments in fs/inode.c.
I've read Peter Salus's book "a Quarter Century of Unix". I've read the
history of early unix development on Dennis Richie's home page, and although
it complains that his original notes came back form the dictation service
misspelling "inode" as "eyenode", it doesn't say what the I stands for. I'm
only about a third of the way into "Life with Unix", but it doesn't seem
like
a particularly technical history so far...
Another question I'm unclear about is "does every userspace-visible memory
allocation have an inode"? Loaded programs are basically mmaped files, and
shared memory is now its own filesystem out of which you mmap stuff. But I
don't know about a process's stack and heap.
For a while I thought that swap could be thought of as a filesystem out of
which the heaps were mapped as sparse files (this is the only explanation
that made sense in early 2.5 when every page used HAD to have swap backing
store, and taking away the mandatory backing store would just be an exercise
in deferred allocation), but that apparently is not the case and I got
disabused of this notion a while back. Instead I learn what a "classzone"
is. Ok...
Then earlier today I wander across kerneltrap's interview with Larry McVoy,
who espouses the viewpoint that Linux VM design should store statistics in
inodes rather than worrying so much about individual pages, and I get
confused again.
Has each process space's heap got an inode? If so, in what filesystem?
Rob
(Yes, I am breaking the internet convention of posting errors rather than
asking questions if you want people to respond. I can come up with some
errors if you'd like. I'm good at that. :)
On Friday 19 July 2002 12:45 am, CaT wrote:
> On Thu, Jul 18, 2002 at 09:38:57PM -0700, Larry McVoy wrote:
> > On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
> > > I've been sitting on this question for years, hoping I'd come
> > > across the answer, and I STILL don't know what the "i" is short for.
> > > Somebody here has got to know this. :)
> >
> > Incore node, I believe. In the original Unix code there was dinode and
> > inode if I remember correctly, for disk node and incore node.
>
> That's a new one. I always thought it was 'information node' so in the
> above it'd be disk information node and just information node.
>
> Makes sense to me in any case. :)
So far I've also received off-list mails saying that it stands for "index"
(this person cited "the design of the unix operating system", by Maurice J
Bach, which I have on my shelf but don't remember that bit from), and another
vote for "indirection" from somebody I recognize as being on this list longer
than I have...
That's it, I'm going to go email Dennis Richie...
Rob
Hi,
On Thu, 18 Jul 2002, Rob Landley wrote:
> That's it, I'm going to go email Dennis Richie...
If you want to be sure whether or not you can rely on index, you better go
ask Maurice. I know another person who should have known that, but he's
dead for quite long now. I never cared, unfortunately.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
On Friday 19 July 2002 01:40 am, Thunder from the hill wrote:
> Hi,
>
> On Thu, 18 Jul 2002, Rob Landley wrote:
> > That's it, I'm going to go email Dennis Richie...
>
> If you want to be sure whether or not you can rely on index, you better go
> ask Maurice. I know another person who should have known that, but he's
> dead for quite long now. I never cared, unfortunately.
>
> Regards,
> Thunder
I emailed dmr but don't expect to hear from him before moring if he actually
notices my email at all.
I did track down my copy of The design of the unix operating system and sure
enough, on page 22, in section 2.2.1 (an overview of the file subsystem):
"The term inode is a contraction of the term <i>index node</i> and is
commonly used in literature on the UNIX system."
That's probably good enough for me, actually. Now my NEXT unanswered
question is why the heck Darpa's "Information Awareness Office" has a picture
of the Bavarian Illuminati in its logo, but I doubt that's something this
list can help me with. Me, I would have picked the gnomes of zurich. Or the
UFOs, for the second attack. Or in the expansion pack, The Networks, since
transferrable power is so useful anyway...
(P.S. I'm not quite kidding: http://www.darpa.mil/iao/ ).
Rob
Rob Landley wrote:
> On Friday 19 July 2002 12:45 am, CaT wrote:
>
>>On Thu, Jul 18, 2002 at 09:38:57PM -0700, Larry McVoy wrote:
>>
>>>On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
>>>
>>>>I've been sitting on this question for years, hoping I'd come
>>>>across the answer, and I STILL don't know what the "i" is short for.
>>>>Somebody here has got to know this. :)
>>>
>>>Incore node, I believe. In the original Unix code there was dinode and
>>>inode if I remember correctly, for disk node and incore node.
>>
>>That's a new one. I always thought it was 'information node' so in the
>>above it'd be disk information node and just information node.
>>
>>Makes sense to me in any case. :)
No it doesn't not. Becouse that would rather describe a super block.
On Thursday 18 July 2002 07:21 pm, Rob Landley wrote:
> That's probably good enough for me, actually. Now my NEXT
> unanswered question is why the heck Darpa's "Information
> Awareness Office" has a picture of the Bavarian Illuminati in
> its logo, but I doubt that's something this list can help me
> with. Me, I would have picked the gnomes of zurich. Or the
> UFOs, for the second attack. Or in the expansion pack, The
> Networks, since transferrable power is so useful anyway...
_You_ are a curious young man. Now curiosity can have
repercussions--but lucky you, you get rewarded with a nice
Vanilla Coke.
I believe you will find its delicate hint of vanilla flavor
alluring, refreshing.
I'm glad you like it. Bruno!
*door slams*
:D
--
Kelledin
"If a server crashes in a server farm and no one pings it, does
it still cost four figures to fix?"
P.S. I can't believe I was able to summon so much of that damn
commercial to memory. I hate vanilla coke. Then again, I can't
believe I was right about the 'i' in inode either.
On July 18, 2002 17:21, Rob Landley wrote:
> That's probably good enough for me, actually. Now my NEXT unanswered
> question is why the heck Darpa's "Information Awareness Office" has a
> picture of the Bavarian Illuminati in its logo, but I doubt that's
> something this list can help me with. Me, I would have picked the gnomes
> of zurich. Or the UFOs, for the second attack. Or in the expansion pack,
> The Networks, since transferrable power is so useful anyway...
That one's easier. The pyramid with the radiant eye is actually the reverse of
the Great Seal of the United States of America, dreamed up by a bunch of
committees shortly after the US gained independence. It also appears on the
one dollar bill. And because it was designed by committee, it's about as
complex as the POSIX standard.
The pyramid signifies strength and duration. It was an appropriate symbol at
the time, because there was an Egypt fad, and everyone though pyramids and
mummy were really novel. The pyramid has thirteen levels, symbolising the
thirteen original states. The partially completed state of the pyramid is
intended to represent the nation under construction. I guess they crammed 38
more levels in at the very tip.
The single opening eye has always been an artistic symbol of omniscience. This
represents the "God" [1] of the founders, and is referred to in the caption
"Annuit Coeptis". This roughly translates to "It has favoured our
undertakings", meaning that the omniscient eye likes the US. The radial lines
originating at the omniscient eye are supposed to stand for it extending
radiance out in to infinity.
> (P.S. I'm not quite kidding: http://www.darpa.mil/iao/ ).
Now, the symbolism used in the IOA logo is poor at best. The omniscient eye
was never supposed to represent the United States itself, but God [1]. Unless
they're calling themselves God lately, they really broke the metaphor by
having the eye looking over the Earth. It just goes to show that the US was a
lot cooler when it was founded than it is now.
-Ryan
[1] Joseph Campbell suggested that the God referred to by the founders was not
the Christian God, but the "God" of logic and reason. One argument for this
may be that the opening eye is also used to represent the "third eye". The
third eye stands for enlightenment and introspection, which is very
suggestive of the sort of God Joseph Campbell talks about. I haven't done
nearly enough independent research to back that up, though.
> The pyramid has thirteen levels, symbolising the
> thirteen original states. The partially completed state of the
pyramid is
> intended to represent the nation under construction. I guess they
crammed 38
> more levels in at the very tip.
37.
38 + 13 = 51. There's only 50 afaik ;).
Nik
CaT <[email protected]>:
> On Thu, Jul 18, 2002 at 09:38:57PM -0700, Larry McVoy wrote:
> > On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
> > > I've been sitting on this question for years, hoping I'd come
> > > across the answer, and I STILL don't know what the "i" is short for.
> > > Somebody here has got to know this. :)
> >
> > Incore node, I believe. In the original Unix code there was dinode and
> > inode if I remember correctly, for disk node and incore node.
>
> That's a new one. I always thought it was 'information node' so in the
> above it'd be disk information node and just information node.
>
> Makes sense to me in any case. :)
I believe the original description was "index node" since it contains
the contents of the file index - dinode was the disk resident file
index node, which is converted to the memory resident version "inode".
This index node also contains the index references to the disk blocks
allocated to the file.
In even earlier OSs (DEC RSX, TOPS 10) the file index table was actually a file
in the filesystem (usually named index.idx (or was it file.idx...). I don't
know what it was called in MULTICs where the UNIX varient would have
started.
Most of these filesystems were based on contigeuous allocation, or allocations
of contigeous segments. Hence the first file on the system would be a
contigeuous file, containing the references to all files. Since it was
contiguous, the files could be referenced directly by index, without
requiring special handling to retrieve pointers to where the next
segment of the index file - which is still true for most filesystems
under UNIX (the really large ones are moving to tree structures which
require multiple lookups just to find the inode entry...). Directory
structures (at least on the ones I worked with) contained:
index number, version, name
triples.
Note - the version number had nothing to do with the file version -
it was used to aid file recovery and was only a reuse count of the index
node. The index node contents had to have the same version number as the
directory entry, or the directory entry was considered invalid. The
file name was a rad50, or sixbit (packed) characters, and sometimes was
stored in both inode and directory - again, for rebuilding the file system.
The pointers in the index node were (block, count) pairs
where the count was the number of blocks in the segment, starting at
"block" location. When the list of pointers in the index node were used
up, the last entry would be another (index number, version) pair pointing
to another index node.
This made it fairly fast for I/O since large chunks of the file could be
loaded in one disk access. Faster access could be had by preallocating
the file (useing the copy utility with a "contig" option).
Fragmentation, however, did force a relatively frequent backup/restore cycle
(took all afternoon on the first Saturday of every month for 8 80MB disks).
Sorry - irrestable nostalgia struck....
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
On Thu, Jul 18, 2002 at 09:38:57PM -0700, Larry McVoy wrote:
> On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
> > I've been sitting on this question for years, hoping I'd come across the
> > answer, and I STILL don't know what the "i" is short for. Somebody here has
> > got to know this. :)
>
> Incore node, I believe. In the original Unix code there was dinode and
> inode if I remember correctly, for disk node and incore node.
So what was that program that was used to fix file system errors called? Started
with a "d". I remembered the name up until a few years ago when I said
something about fixing filesystems with whatever it was and adb in front of Dave Miller
who seemed ready to rush me off to the museum to be exhibited in the paleology section.
Now I'm too old to even remember the name.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
Rob Landley <[email protected]> writes:
> On Friday 19 July 2002 12:45 am, CaT wrote:
> > On Thu, Jul 18, 2002 at 09:38:57PM -0700, Larry McVoy wrote:
> > > On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
> > > > I've been sitting on this question for years, hoping I'd come
> > > > across the answer, and I STILL don't know what the "i" is short for.
> > > > Somebody here has got to know this. :)
> > >
> > > Incore node, I believe. In the original Unix code there was dinode and
> > > inode if I remember correctly, for disk node and incore node.
> >
> > That's a new one. I always thought it was 'information node' so in the
> > above it'd be disk information node and just information node.
> >
> > Makes sense to me in any case. :)
>
> So far I've also received off-list mails saying that it stands for
> "index" (this person cited "the design of the unix operating
> system", by Maurice J Bach, which I have on my shelf but don't
> remember that bit from), and another vote for "indirection" from
> somebody I recognize as being on this list longer than I have...
Andrew S. Tanenbaum claims it's index nodes in 'Modern Operating
Systems, 2nd ed.'. He also wants them spelled i-node.
--
M?ns Rullg?rd
[email protected]
It should be spelled it GNU/i-node.
} Andrew S. Tanenbaum claims it's index nodes in 'Modern Operating
} Systems, 2nd ed.'. He also wants them spelled i-node.
On Fri, 19 Jul 2002, Cort Dougan wrote:
> It should be spelled it GNU/i-node.
>
> } Andrew S. Tanenbaum claims it's index nodes in 'Modern Operating
> } Systems, 2nd ed.'. He also wants them spelled i-node.
*forwards to RMS*
stallman ... as much as i respect the guy for his contributions to the
open source movement, i can't help but ask myself why he's such a baby
about the little things like that.
Kelsey Hudson [email protected]
Software Engineer/UNIX Systems Administrator
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------
Rob Landley <[email protected]> writes:
>
> I've been sitting on this question for years, hoping I'd come across the
> answer, and I STILL don't know what the "i" is short for. Somebody here has
> got to know this. :)
Boy, how newbie can you get? Fortunately, you've got lots of people
setting you straight, and they've given you all those different
answers to choose from! ;)
> Another question I'm unclear about is "does every userspace-visible memory
> allocation have an inode"? Loaded programs are basically mmaped files, and
> shared memory is now its own filesystem out of which you mmap stuff. But I
> don't know about a process's stack and heap.
I'd say a mapping "has an inode" if its associated "vm_area_struct"
has a non-NULL "->vm_file" (in which case the inode number is stored
in "->vm_file->f_dentry->d_inode->i_ino"). By this standard, it's
pretty easy to see what parts of a process's address space have an
inode. Just "cat /proc/nnn/maps". Each map line will have an inode
number in the fifth column or zero if there's no associated inode.
In general, executable text (including shared libraries) and other
pages mmapped from real files have inodes. Pages mmapped anonymously
don't---if they're private---or do---if they're shared. In the latter
case, they have a nameless (i.e., unlinked) inode in the shmfs though
its name shows up as "/dev/zero" in "/proc/nnn/maps". Both System V
and POSIX shared memory have inodes in shmfs, I believe. Pages
allocated with brk/sbrk (including heap for C programs) don't have an
inode.
Mmapping "/dev/zero" is a special case. Private (or read-only) maps
of "/dev/zero" will be associated with "/dev/zero"'s inode. Make a
shared, writable map of "/dev/zero", and it acts like a shared
anonymous page: it's associated with an unlinked inode in shmfs, but
its name shows up as "/dev/zero" in "/proc/nnn/maps".
Mmapping other devices could do anything... By default, the maps stay
associated with the device inode but could be changed by the device
code at its whim.
> Then earlier today I wander across kerneltrap's interview with Larry McVoy,
> who espouses the viewpoint that Linux VM design should store statistics in
> inodes rather than worrying so much about individual pages, and I get
> confused again.
Well, if I recall correclty, Larry made it clear in that interview
that he wasn't 100% sure how the Linux MM was doing things right now,
and he certainly wasn't claiming his scheme would plug right in. If
his scheme were to be adopted, presumably we would want to introduce
inodes associated with private, anonymous pages (including brk/sbrk
pages).
--
Kevin Buhr <[email protected]>
Larry McVoy wrote:
>
> On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
> > I've been sitting on this question for years, hoping I'd come across the
> > answer, and I STILL don't know what the "i" is short for. Somebody here has
> > got to know this. :)
>
> Incore node, I believe. In the original Unix code there was dinode and
> inode if I remember correctly, for disk node and incore node.
According to Uresh Vahalia in "Unix Internals, The New Frontiers",
"The word inode derives from index node. ... Whenever it is ambiguous,
we use the term on-disk inode to refer to the on-disk data structure
(struct dinode) and in-core inode to refer to the in-memory structure
(struct inode)
On Fri, 2002-07-19 at 10:20, [email protected] wrote:
> On Thu, Jul 18, 2002 at 09:38:57PM -0700, Larry McVoy wrote:
> > On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
> > > I've been sitting on this question for years, hoping I'd come across the
> > > answer, and I STILL don't know what the "i" is short for. Somebody here has
> > > got to know this. :)
> >
> > Incore node, I believe. In the original Unix code there was dinode and
> > inode if I remember correctly, for disk node and incore node.
>
> So what was that program that was used to fix file system errors called? Started
> with a "d". I remembered the name up until a few years ago when I said
> something about fixing filesystems with whatever it was and adb in front of Dave Miller
> who seemed ready to rush me off to the museum to be exhibited in the paleology section.
> Now I'm too old to even remember the name.
Sure you're not thinking of "fsdb"?
-g
On Sat, Jul 20, 2002 at 10:22:07AM -0400, Georg Nikodym wrote:
> On Fri, 2002-07-19 at 10:20, [email protected] wrote:
> > On Thu, Jul 18, 2002 at 09:38:57PM -0700, Larry McVoy wrote:
> > > On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
> > > > I've been sitting on this question for years, hoping I'd come across the
> > > > answer, and I STILL don't know what the "i" is short for. Somebody here has
> > > > got to know this. :)
> > >
> > > Incore node, I believe. In the original Unix code there was dinode and
> > > inode if I remember correctly, for disk node and incore node.
> >
> > So what was that program that was used to fix file system errors called? Started
> > with a "d". I remembered the name up until a few years ago when I said
> > something about fixing filesystems with whatever it was and adb in front of Dave Miller
> > who seemed ready to rush me off to the museum to be exhibited in the paleology section.
> > Now I'm too old to even remember the name.
>
> Sure you're not thinking of "fsdb"?
icheck and dcheck - thanks to the people who sent me mail reminding me.
>
> -g
>
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
http://www.fsmlabs.com http://www.rtlinux.com
--------- Received message begins Here ---------
>
>
> --=-JpG6tr/3TXNgZxkgIDvS
> Content-Type: text/plain
> Content-Transfer-Encoding: quoted-printable
>
> On Fri, 2002-07-19 at 10:20, [email protected] wrote:
> > On Thu, Jul 18, 2002 at 09:38:57PM -0700, Larry McVoy wrote:
> > > On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote:
> > > > I've been sitting on this question for years, hoping I'd come across =
> the=20
> > > > answer, and I STILL don't know what the "i" is short for. Somebody h=
> ere has=20
> > > > got to know this. :)
> > >=20
> > > Incore node, I believe. In the original Unix code there was dinode and
> > > inode if I remember correctly, for disk node and incore node.
> >=20
> > So what was that program that was used to fix file system errors called? =
> Started
> > with a "d". I remembered the name up until a few years ago when I said
> > something about fixing filesystems with whatever it was and adb in front =
> of Dave Miller
> > who seemed ready to rush me off to the museum to be exhibited in the pale=
> ology section.
> > Now I'm too old to even remember the name.
>
> Sure you're not thinking of "fsdb"?
No - this was done before fsck - though fsdb did exist - for manual
interaction with the disk structure on a block by block basis.
I believe he is referring to
dcheck - which did directory traversals looking for lost files
Associated with this is:
ncheck - which checked the structure of each file.
The functions of fsck were combined from these two utilities (and added
some more) when bitmap allocation was being added to the file system.
Previous to this, all documentation I've seen for disk structure used a
"free list" chain of unused blocks, where deleted files were put. The
disk free list was used in a LIFO structure to minimise fragmentation, and
preserve the largest free disk segment for new file allocations.
You have to go back to UNIX release 6 or 7 for the last real uses of these
commands before fsck. They did exist in UNIX System V release 2, but only
as "depreciated" utilities not to be used anymore. They did work, but were
superceeded, and did not exist in the next release as I understand. (I had
release 1/2 but did not get 3).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
On Thu, 2002-07-18 at 15:33, Rob Landley wrote:
> I've been sitting on this question for years, hoping I'd come across the
> answer, and I STILL don't know what the "i" is short for. Somebody here has
> got to know this. :)
>
Two plausible definitions:
The Magic Garden Explained calls them "information nodes".
A really old (1983) Byte Book called Introducing the Unix System has
this to say:
A file in the UNIX system is described by an object called an
"i-node". We think that the name means "interior node", since
the UNIX file-system is (in principle at least) a directed
graph. For every file there is a single i-node that describes
that file, and contains pointers to blocks that comprise that
file.
So, what do you _want_ it to mean? :-)
- Joe DiMartino
On Thu, Jul 18, 2002 at 06:33:54PM -0400, Rob Landley wrote the words in effect of:
> From: Rob Landley <[email protected]>
> To: [email protected]
> Subject: Alright, I give up. What does the "i" in "inode" stand for?
> I've been sitting on this question for years, hoping I'd come across the
> answer, and I STILL don't know what the "i" is short for. Somebody here has
> got to know this. :)
The "I" in "Inode" stands for "Index". Think of it in this way, the
Inode is unique, it is the "index" by which you refer to a specific
file.
FWIW, this definition is used in many computer science texts, also in
JFS Layout paper I think. I confirmed my definition with various
sources.
> [...]
Hope this helps. Btw, this is the first time I am posting to lkml.
Thank You.
--
Hiten Pandya
http://www.unixdaemons.com/~hiten
[email protected], [email protected], [email protected]
PGP: http://pgp.mit.edu:11371/pks/lookup?search=Hiten+Pandya&op=index
Rob Landley wrote:
> I've been sitting on this question for years, hoping I'd come across the
> answer, and I STILL don't know what the "i" is short for. Somebody here has
> got to know this. :)
>
> I know what an inode IS (although it took me almost a year to figure this
> out, way back when), but I don't know what the name means.
>
> I've been following this list for years now, and nobody's ever actually said
> what the i stands for, and neither do the (sparse) comments in fs/inode.c.
> I've read Peter Salus's book "a Quarter Century of Unix". I've read the
> history of early unix development on Dennis Richie's home page, and although
> it complains that his original notes came back form the dictation service
> misspelling "inode" as "eyenode", it doesn't say what the I stands for. I'm
> only about a third of the way into "Life with Unix", but it doesn't seem like
> a particularly technical history so far...
I have followed the LKML for only about 2 months. I have been
thinking of posting something similar. ( just not 'bout i-nodes )
Someone pointed out earlier in this thread:
"How Newbie can one get?"
To my point of view this topic does not fall into the "Newbie"
cathegory. Rather I would choose to call this
a Linux kernel "Alienate" topic.
Rob has actually made severe long time efforts to take on Unix,
and just as I know I will, he has failed.
As I my self feel very alienated to some of the structural
names in a Unix environment I actually applaud Rob for daring
to start, and maintain this topic in here. ( Not that I find
any of the guys in here to be either scary or unpleasant in
any way. Just buzy doing some great ( but mysterious ) work )
I can easily cope with the Idea that the I in I-node stands for
whatever one likes it to be. The I-node context makes very good
sense to me when you put it to work in FS context. The name
I-node is as I see it, close to semantic rape. (as I also find
some of the K&R/ANSI C keywords to be )
What bothers my self a bit more in the kernel context, and thus
makes me an even more eager "Kernel alienate" than I believe Rob
to be, are the "atomic_" calls/functions and their semantic origin.
I believe that every Unix has "atomic_" calls all though perhaps
differently designed. And I totally fail to understand why some
one decided to name theese functions "atomic_"
To my own thinking, the atomical parts of any process in a
computer are puny little switches that are mostly referred to as
bits, and theese bits have all the software support they can get
even with out any "atomic_" call. I don't find anything even
remotely close to an electron microscope within Unix either.
So I fail.
Perhaps you Rob can clear me out on this one though? I mean:
You have actually managed to endure, being a kernel alienate
for a much longer time than I can hope for my self.
Other words in this ML (and in too many other places =( ) that
make my own brain go rivetted and short circuit are the "foo"
and/or "bar", not to mention the "foobar" place holder.
I realize that most folks In LKML use "foo", "bar" and it's dad,
"foobar" with outmost joy and that there is complete and utter
understanding of what the "foos" and "bars" actually stand for
in your contemporary discussion partners reasoning scheeme.
Or is it?
Some times I notice that people who write pseudo code find good
replacer words which actually explain the place holders function
context, where the average linux kernel posters simply puts their
"foo","bar" or "foobar" But I have yet Not noticed this horrificly
effective way of clarifying ones intentions anywhere in the postings
to the linux kernel mailing list. Therefore I conclude that you must
all be telepathic phenomenons, or that you have all found some other
odd or mysterious way of mentally tuning in the intentions of your
contemporary discussion partners.
This conclusion is primarily based upon that I'm actually success-
full in typing in, and saving this followup on a linux box, that
boots up almost without any errors every single time I push the
power button.
This might not actually have to be the truth, however.
Suppose that you do missunderstand your discussion partner frequently.
So you each type in some related patches and send them of to linus(?)
linus (or whom-ever) sends them back, saying "half is buggy" So you're
back discussing again. This time you have half the code bugfree so
you only need to discuss the buggy half. You discuss it, missunder-
stand each others frequently again because of some "foos" and "bars"
and thus send in another patch, which is refused as being
"quarterly-buggy", and so on...
So which one is it?
> (Yes, I am breaking the internet convention of posting errors rather than
> asking questions if you want people to respond. I can come up with some
> errors if you'd like. I'm good at that. :)
Thank you very much for this topic, Rob.
kind regards Daniel Mose.
On Thu, 25 Jul 2002 02:24:54 +0200
Daniel Mose <[email protected]> wrote:
> Rob Landley wrote:
> [snip]
> What bothers my self a bit more in the kernel context, and thus
> makes me an even more eager "Kernel alienate" than I believe Rob
> to be, are the "atomic_" calls/functions and their semantic origin.
> I believe that every Unix has "atomic_" calls all though perhaps
> differently designed. And I totally fail to understand why some
> one decided to name theese functions "atomic_"
>
> To my own thinking, the atomical parts of any process in a
> computer are puny little switches that are mostly referred to as
> bits, and theese bits have all the software support they can get
> even with out any "atomic_" call. I don't find anything even
> remotely close to an electron microscope within Unix either.
> So I fail.
Well, this one is easy enough.
"Atomic" comes from the older-than-old meaning of the word, which is,
roughly, "unsplittable" or "undivisible". Whether it uses magical CPU
instructions, or just some sort of locking mechanism, an atomic
operation is one that cannot be observed, or interfered with, "half
done".
This has lots of uses with databases, and is a major requirement there
(and a basic database book will probably explain it better than I), but
it's a big thing when you're designing an SMP/preemptive/preemptible
kernel, too. :)
Hope I was enlightening and not just boring
--hobbs
On Thu, Jul 25, 2002 at 02:24:54AM +0200, Daniel Mose wrote:
> What bothers my self a bit more in the kernel context, and thus
> makes me an even more eager "Kernel alienate" than I believe Rob
> to be, are the "atomic_" calls/functions and their semantic origin.
> I believe that every Unix has "atomic_" calls all though perhaps
> differently designed. And I totally fail to understand why some
> one decided to name theese functions "atomic_"
It is from the Greek
a -- not
tomos -- cuttable
I think it was Aristotle who theorized the existance of the
atom. He described it by discussing an apple. You can cut
an apple in half. each piece you can cut in half again.
Eventually you would get to a piece, invisibly small, that
could not be cut in half. That was his atom.
Of course scientists assigned the term to something that
could indeed be split. Of course you know what happens when
you split the atom...
In programming we describe as atomic any action that cannot
be split (a read(2) from a serial device cannot return just 3
bits) or an action containing multiple sub-actions that if
split/interrupted causes breakage. If you interrupt an
atomic_* it will set of a chain reaction and the OS will
explode :)
>
> To my own thinking, the atomical parts of any process in a
> computer are puny little switches that are mostly referred to as
> bits, and theese bits have all the software support they can get
> even with out any "atomic_" call. I don't find anything even
> remotely close to an electron microscope within Unix either.
> So I fail.
>
> Perhaps you Rob can clear me out on this one though? I mean:
> You have actually managed to endure, being a kernel alienate
> for a much longer time than I can hope for my self.
>
> Other words in this ML (and in too many other places =( ) that
> make my own brain go rivetted and short circuit are the "foo"
> and/or "bar", not to mention the "foobar" place holder.
>
> I realize that most folks In LKML use "foo", "bar" and it's dad,
> "foobar" with outmost joy and that there is complete and utter
> understanding of what the "foos" and "bars" actually stand for
> in your contemporary discussion partners reasoning scheeme.
>
> Or is it?
>
> Some times I notice that people who write pseudo code find good
> replacer words which actually explain the place holders function
> context, where the average linux kernel posters simply puts their
> "foo","bar" or "foobar" But I have yet Not noticed this horrificly
> effective way of clarifying ones intentions anywhere in the postings
> to the linux kernel mailing list. Therefore I conclude that you must
> all be telepathic phenomenons, or that you have all found some other
> odd or mysterious way of mentally tuning in the intentions of your
> contemporary discussion partners.
The terms foo, bar, foobar, sna, etc in psuedocode stand for
"something having a name" We use them in places where the
actual name doesn't matter for the sake of the discussion.
The "good replacer words" can often be almost-real or
unintentially real name and cause confusion or divert the
functional discussion into a discussion (argument) over
names. They are sometimes also used to mean "you make up a
name that has meaning for your purpose".
Once in a while though FUBAR and SNAFU are used in their
classic naval-derived sense. such as when a certain POTUS
told the world that a grave government agency error was a
SNAFU implying that such erros were "Situation Normal".
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: [email protected]
Remember Cernan and Schmitt
On July 24, 2002 10:43 pm, jw schultz wrote:
> I think it was Aristotle who theorized the existance of the
> atom. He described it by discussing an apple. You can cut
> an apple in half. each piece you can cut in half again.
> Eventually you would get to a piece, invisibly small, that
> could not be cut in half. That was his atom.
I think you're referring to Democritus, but I can't find the reference in my
books...
Have fun,
Chris
--
I haven't lost my mind. It's backed up on tape somewhere.
Christian Lavoie, [email protected]
http://www.christianlavoie.com
On Wed, Jul 24, 2002 at 11:18:49PM -0400, Christian Lavoie wrote:
> On July 24, 2002 10:43 pm, jw schultz wrote:
> > That was his atom.
>
> I think you're referring to Democritus, but I can't find the reference in my
> books...
He is. Leon Lederman talks extensively about Democritus in "The God
Particle", a physics text many geek have probably read.
And according to Lederman, he described it with a chunk of cheese.
Ross Vandegrift
[email protected]
Hi,
On Thu, 25 Jul 2002, Daniel Mose wrote:
> Other words in this ML (and in too many other places =( ) that
> make my own brain go rivetted and short circuit are the "foo"
> and/or "bar", not to mention the "foobar" place holder.
>
> I realize that most folks In LKML use "foo", "bar" and it's dad,
> "foobar" with outmost joy and that there is complete and utter
> understanding of what the "foos" and "bars" actually stand for
> in your contemporary discussion partners reasoning scheeme.
>
> Or is it?
Well, there's indeed a meaning behind it, apart from "fucked over and over
beyond all repair."
Firstly, there was foo, way back when in the 1930s when I was a bit
younger. Its meaning was not always technical, I think it came from some
kind of comic strip, but I'm not sure.
It became a buzzword soon, it was used all over. Then came up the
technicians. Remembering the german word "furchtbar" (meaning "terrible",
actually) they introduced the term fubar, fucked up beyond all repair. It
later transformed to the well-known foobar. Actually, think of foobar as a
foo with a bar over it - foo inverted.
Later it was used in its current meaning by e.g. dec in their decsys
manuals, go read it if you like, I don't have them handy.
Regards,
Thunder
--
(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o? K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y-
------END GEEK CODE BLOCK------
On Thu, 2002-07-25 at 04:18, Christian Lavoie wrote:
> On July 24, 2002 10:43 pm, jw schultz wrote:
> > I think it was Aristotle who theorized the existance of the
> > atom. He described it by discussing an apple. You can cut
> > an apple in half. each piece you can cut in half again.
> > Eventually you would get to a piece, invisibly small, that
> > could not be cut in half. That was his atom.
>
> I think you're referring to Democritus, but I can't find the reference in my
> books...
Leucippus of Miletus, about 440BC. Democritus was his pupil who refined
and extended it along with him.
Can we go back to the topic now
Daniel Mose <[email protected]>:
> What bothers my self a bit more in the kernel context, and thus
> makes me an even more eager "Kernel alienate" than I believe Rob
> to be, are the "atomic_" calls/functions and their semantic origin.
> I believe that every Unix has "atomic_" calls all though perhaps
> differently designed. And I totally fail to understand why some
> one decided to name theese functions "atomic_"
>
> To my own thinking, the atomical parts of any process in a
> computer are puny little switches that are mostly referred to as
> bits, and theese bits have all the software support they can get
> even with out any "atomic_" call. I don't find anything even
> remotely close to an electron microscope within Unix either.
> So I fail.
This reference has to do with operations that must be completed
against memory WITHOUT any intervening accesses. The reference "atomic_"
comes from "non-divisible" operations where the operation cannot
or must not be subdivided any further (also from physics where atoms
cannot normally be subdivided).
Most of the time, a single memory reference is considered an atomic
operation. HOWEVER, this fails when you have various sized units. The
data structure is thought of as being composed of multiple elements
of the smallest size (and I'll get to what is considered "smallest size"
later).
First, on a uniprocessor, the processing unit minimum is a byte. Yet many
data elements require 2 or 4 bytes. Using a single instruction to access
the unit would seem to be indivisible... but isn't. Consider the possibility
of a 2 byte data fetch - if one byte is at the end of a memory page, and
the next byte is in the following page, AND that following page is out of
memory... This turns a simple 2 byte fetch (posed here as a single instruction
operation) may turn into several hundred, to several thousand, before that
2 byte sized unit may be fetched. This isn't atomic - meaning indivisible.
The "smallest size" of a system depends on the hardware implementation -
A two byte fetch may be implemented as a single 8 or 16 byte fetch depending
on how the CPU/cache/memory bus/memory are connected. This introduces other
conditions on the definition of "atomic_". If there are two CPUs active then
either, or both, CPUs may access the same data. These access will actually
not occur simultaneously (unless dual ported memory which is truly rare) but
what happens is an interleavling of access. Assuming a bus of 16 bits that
transfers 16 bytes per access - the first CPU would start the activity
transferring 2 bytes. After that transfer, the first CPU starts the next 2
bytes - and the second CPU starts the first 2 bytes. This repeats until all
16 bytes are transferred to both CPUs. This action is not atomic either.
This does not cause problems UNLESS you are updating data. Say removing a
node from a linked list. At this time one CPU may put 2 bytes of pointer back
into the structure (out of 4 bytes), while the second CPU reads the old data,
mixed with the new data. At this point, the operation must be treated more like
a database "transaction", where no access is granted until the transaction is
complete.
The "atomic_" functions implement a method to force all other access to the
data to wait UNTIL the operation (say removing a node from a linked list)
is complete. In many cases, instead of the entire operation being "atomic",
what is implemented is a flag that is "atomic". If the flag is set, wait.
if the flag is clear, set it and continue. NOTE: this is a complex operation
that requires more than on instruction (depending on CPU, instruction set, and
whether there are multiple CPUs). An instruction for this "test and set" can
exist, AND be atomic when used with one CPU. It doesn't necearily mean it is
atomic when used with multiple CPUs. Hence - the functions would implement
a method to support a system wide "atomic" operations that are guaranteed
to be indivisible, even with multiple CPUs in the system.
....
> I realize that most folks In LKML use "foo", "bar" and it's dad,
> "foobar" with outmost joy and that there is complete and utter
> understanding of what the "foos" and "bars" actually stand for
> in your contemporary discussion partners reasoning scheeme.
"foo", "bar" and "foobar" (and sometimes "fubar" which I believe is the
origin of the terms) are old slang (see hacker dictionary). They are used
to represent something much more complicated to write...
ie:
void *foobar()
would mean "a function returning a pointer to a void type" where the actual
NAME of the function is not really relevent to the topic. This can be carried
to connect things like the above together as a form of prototype specification,
used only in describing the prototype, and is not the prototype itself.
No, it isn't 100% accurate. And it is easily misunderstood, especially if
english (the US style) is mixed with the (British syle) and mixed with
non-english transliterations of other idiomatic language structures.
But it means the participants in the discussion LEARN more about communicating
with others - sometimes emotionally, sometimes with laughter, sometimes just
a "oh, so that is what you mean...".
Sometimes it may take a little longer to get to a solution, but it seems to
be more fun, and the result is usually much better than what happens in more
regimented organizations.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
Daniel Mose <[email protected]> writes:
>
> Someone pointed out earlier in this thread:
> "How Newbie can one get?"
*I* said that, and it should be noted that it was completely obvious
from context that it was tongue in cheek:
| Boy, how newbie can you get? Fortunately, you've got lots of people
| setting you straight, and they've given you all those different
| answers to choose from! ;)
(Get it? The obvious, "newbie" question is answered by the experts in
a dozen different ways. HAW HAW.)
Anyway, I hope you realized that.
> I can easily cope with the Idea that the I in I-node stands for
> whatever one likes it to be. The I-node context makes very good
> sense to me when you put it to work in FS context. The name
> I-node is as I see it, close to semantic rape. (as I also find
> some of the K&R/ANSI C keywords to be )
Is "semantic rape" supposed to be good or bad?
The name "inode" (or i-node or I-node or eye-node---haw haw) doesn't
have to mean anything as long as it's conveniently short and
immediately evocative to people who use the name. On its face,
calling something a "widget" isn't very descriptive either, yet its
meaning is obvious enough in the context of GUI programming. See also
the Linux kernel's "dentry" and "skbuff".
People don't invent these shared languages to alienate newcomers.
They are invented to facilitate efficient communication and, just as
importantly, to encapsulate big, complicated ideas in tiny,
manipulable pretend-words. They facilitate *thought* (and, so, the
design process) as much as they facilitate communciation.
That's good, right?
> What bothers my self a bit more in the kernel context, and thus
> makes me an even more eager "Kernel alienate" than I believe Rob
> to be, are the "atomic_" calls/functions and their semantic origin.
This has been explained by others, but let me note that the Jargon
File is an excellent resource for these types of questions:
http://www.tuxedo.org/~esr/jargon/
It doesn't include "inode" (which falls a little outside its scope),
but it has entries for "atomic", "foo", "bar", and "foobar".
> Suppose that you do missunderstand your discussion partner frequently.
>
> So you each type in some related patches and send them of to linus(?)
> linus (or whom-ever) sends them back, saying "half is buggy" So you're
> back discussing again. This time you have half the code bugfree so
> you only need to discuss the buggy half. You discuss it, missunder-
> stand each others frequently again because of some "foos" and "bars"
> and thus send in another patch, which is refused as being
> "quarterly-buggy", and so on...
By definition, "foo"s and "bar"s are ambiguous. That's why they
should be used sparingly. Typically they're used in little examples
of shell or C code where you need a *name*, but it's exact value and
meaning aren't important, like so:
>> Hey, there's a bug in the kernel! Do "ln -s foo foo; mkdir foo"
>> and watch the fireworks.
They're rarely used to talk about new data structures except at the
earliest speculative design state.
--
Kevin Buhr <[email protected]>
> It became a buzzword soon, it was used all over. Then came up the
> technicians. Remembering the german word "furchtbar" (meaning "terrible",
> actually) they introduced the term fubar, fucked up beyond all repair. It
> later transformed to the well-known foobar. Actually, think of foobar as a
> foo with a bar over it - foo inverted.
>
> Later it was used in its current meaning by e.g. dec in their decsys
> manuals, go read it if you like, I don't have them handy.
DEC also used fubar to refer to the Failed UniBus Access Register on a VAX, but I think that was either a backronym, or thought up by somebody who wasn't already aware of the other meaning.
On Thursday 25 July 2002 02:03 am, Thunder from the hill wrote:
> Hi,
>
> On Thu, 25 Jul 2002, Daniel Mose wrote:
> > Other words in this ML (and in too many other places =( ) that
> > make my own brain go rivetted and short circuit are the "foo"
> > and/or "bar", not to mention the "foobar" place holder.
> >
> > I realize that most folks In LKML use "foo", "bar" and it's dad,
> > "foobar" with outmost joy and that there is complete and utter
> > understanding of what the "foos" and "bars" actually stand for
> > in your contemporary discussion partners reasoning scheeme.
> >
> > Or is it?
>
> Well, there's indeed a meaning behind it, apart from "fucked over and over
> beyond all repair."
>
> Firstly, there was foo, way back when in the 1930s when I was a bit
> younger. Its meaning was not always technical, I think it came from some
> kind of comic strip, but I'm not sure.
The comic strip was "Smokey Stover". Eric recently found a lot more
backstory on the word "foo" and updated the jargon file entry.
http://www.tuxedo.org/~esr/jargon/html/entry/foo.html
On Friday 19 July 2002 09:06 pm, Kelsey Hudson wrote:
> On Fri, 19 Jul 2002, Cort Dougan wrote:
> > It should be spelled it GNU/i-node.
> >
> > } Andrew S. Tanenbaum claims it's index nodes in 'Modern Operating
> > } Systems, 2nd ed.'. He also wants them spelled i-node.
>
> *forwards to RMS*
>
> stallman ... as much as i respect the guy for his contributions to the
> open source movement, i can't help but ask myself why he's such a baby
> about the little things like that.
Um, because I sort of tried to explain marketing to him, back when I was a
contractor at IBM in late 1998? (For which I would like to apologize to the
community at large. I MEANT well...)
Okay, time to come clean. Back then the fsf web page had a whole "don't call
the OS linux!" section, and I emailed Stallman to object. Linux was a
recognizable and growing operating system brand name, while the Gnu project
was largely seen as a tool vendor in the wider community and "Hurd" meant
nothing to most people (it could be a game or a spreadsheet for all we knew,
or a floor wax for that matter). So fighting against the Linux name was
explicitly counterproductive from a marketing standpoint. If we wanted to
get people to use "Linux", they had probably at least heard of it. Saying
"It's not Linux!" would just confuse them. Stallman's anti-linux crusade was
diminishing one of free sotware's single biggest assets.
The REASON he wanted to do this, according to his web page, was that the hurd
would replace the linux kernel. I told him that if he really did want to
position "Gnu Hurd" as an upgrade to "Gnu Linux", as his web page said, he
first had to attach the GNU name to Linux, sort of like "kellog's raisin
bran", "bud lite", or the way the "Turbo" name allowed Borland to sell many
different types of compilers under one family (Turbo Basic, Turbo Pascal,
Turbo C, Turbo C++. Or Kellog's Rasin Bran, Bud Lite, etc...)
I exchanged three or four emails with him, and he agreed to stop trying to
stop the use of the word Linux and instead promote the GNU organization more,
and highlight its achievements and contributions to Linux. It seemed like a
good thing at the time...
I would like to apologize to the community at large. I kind of got buried in
work and dropped my half of the conversation for a month or two, and then
this "GNU/Linux" thing hit the headlines and I winced a lot. It had turned
into an ego thing and he'd completely missed the marketing point I'd been
trying to make, he had no product to promote except himself and blowing your
own horn has ramifications that deprive it of effectiveness... Anyway, I
emailed him again and tried to go over some of the problems with his first
attempt at marketing, but he was on the road and buried in email, and
generally wasn't listening anymore...
I was also naieve enough back then that I didn't realise the marketing niche
I was pointing him at was already filled by distributions: Red Hat Linux,
Slackware Linux, etc. The last distribution I'd used at that point was SLS.
:) I actually thought the FSF was trying to put out a Linux distribution.
(Well they did -- Debian -- but the project forked away and disassociated
itself from them politically. (Lots of projects seem to do that...) I think
the FSF's web page was a bit out of date when I was trying to catch back up
on Linux after a long digression into OS/2 and Java. Although Debian is
still sort of aligned with the FSF, and as such is the only Linux
distribution to listen to stallman enough to slap GNU/ on their official
name. Or to try to make the Hurd actually run. I think it was debian's web
page that pointed me back to gnu.org at the time, actually...)
So now you know. Once again, I am deeply sorry. At least he stopped telling
people not to use the word "Linux" at all for the name of the OS...
Rob
(Last time I spoke to him, which was quite a while ago now, he had a similar
problem with "intellectual property". The whole of the FSF is one big
crusade about the scope and application of intellectual property law, and
that's really his main area of strength, but he doesn't like to use the
phrase "intellectual property", which puts him at a bit of a disadvantage
discussing it if you ask me...)
Daniel Mose <[email protected]> wrote
>Rob Landley wrote:
>> I've been sitting on this question for years, hoping I'd come across the
>> answer, and I STILL don't know what the "i" is short for. Somebody here has
>> got to know this. :)
{ foobar.. }
>I have followed the LKML for only about 2 months. I have been
>thinking of posting something similar. ( just not 'bout i-nodes )
I' ve cut and pasted among the anwers a bit, since
everone seems to be quoting similar parts, and I made
it into one longer answer instead of several (long)
answers. By doing so anybody will also be able to quote
the answers in this letter without adding one subthread
for each person that is quoted. If this method feels
uncomfortable. Do say so. It is basically the good old
Q+A method.
As I my self am not a LK developer, I will direct any
further feedback directly to persons that target this topic
and my older posting, to save bandwith and threads. Anyone
that recieves a letter from me is of course free to quote
it on LKML.
Before I continue on I am a bit curious about another
question that seems a bit related to topic
" Alright, I give up..."
Q : I'm wondering how many out of a 100 linux developers
it is that does NOT actually have an old Unix back ground ?
It would interest me to know even if it is just a brief
and uncertain calculation
{ fubar..}
>a Linux kernel "Alienate" topic.
[snip]
ah! that word felt much better!
===========================================================
Kevin Buhr <[email protected]> wrote
>| Boy, how newbie can you get? Fortunately, you've got lots of people
>| setting you straight, and they've given you all those different
>| answers to choose from! ;)
>
>(Get it? The obvious, "newbie" question is answered by the experts in
>a dozen different ways. HAW HAW.)
>
>Anyway, I hope you realized that.
Dear Kevin
I wanted to clear out a point that no-one had mentioned
earlier in the topic, so I used your previous words in doing so.
It was not a personal remark. That's why I chose to only focus
on your words and not on your person.
I wrote:
>> I can easily cope with the Idea that the I in I-node stands for
>> whatever one likes it to be. The I-node context makes very good
>> sense to me when you put it to work in FS context. The name
>> I-node is as I see it, close to semantic rape. (as I also find
>> some of the K&R/ANSI C keywords to be )
>
>Is "semantic rape" supposed to be good or bad?
Perhaps one could say enforced connection to context instead, but
I find "semantic rape" to be more in tune with my own perception.
I do suppose that we have somewhat different ways in
approach towards Unix:
>The name "inode" (or i-node or I-node or eye-node---haw haw) doesn't
>have to mean anything as long as it's conveniently short and
>immediately evocative to people who use the name.
If I were to use words like f ex I-nodes when I describe f ex
ext2fs storage layout to a unknowing but receptive friend,
he would either assume that I was turning into a geek, or that
he was being bullied by me. ( I have tried once. )
>calling something a "widget" isn't very descriptive either, yet its
>meaning is obvious enough in the context of GUI programming.
I actually find the word "widget" to be fairly clear.
>See also the Linux kernel's "dentry" and "skbuff".
I have only read about "d-entries" as yet, I didn't have any
problems with the IMO semantically sane reference from "dir_ent".
>People don't invent these shared languages to alienate newcomers.
Are you sure ? =-0
>They are invented to facilitate efficient communication and, just as
>importantly, to encapsulate big, complicated ideas in tiny,
>manipulable pretend-words. They facilitate *thought* (and, so, the
>design process) as much as they facilitate communciation.
Apparently to you and to a lot of others perhaps.
I guess that this is where we don't agree, and I prove to
be an "Alienate."
I consider great ideas to be small and fairly simple, for instance.
And, yes I do consider Linux as a system to be a Great Idea
so far.
>That's good, right?
Do we really have to share the same points of view?
kind regards
/Daniel Mose
====================================================================0
====================================================================0
>On Thu, Jul 25, 2002 at 02:24:54AM +0200, Daniel Mose wrote:
>> What bothers my self a bit more in the kernel context, and thus
>> makes me an even more eager "Kernel alienate" than I believe Rob
>> to be, are the "atomic_" calls/functions and their semantic origin.
>> I believe that every Unix has "atomic_" calls all though perhaps
>> differently designed. And I totally fail to understand why some
>> one decided to name theese functions "atomic_"
Albert D. Cahalan <[email protected]> wrote
>
>To be an "atom" is to be indivisible. The term comes from
>ancient philosophy. An atomic operation happens all at once.
>
Thank's Albert for making your time mine.
========================================================================
Andrew Rodland <[email protected]> wrote
>Well, this one is easy enough.
>"Atomic" comes from the older-than-old meaning of the word, which is,
>roughly, "unsplittable" or "undivisible". Whether it uses magical CPU
>instructions, or just some sort of locking mechanism, an atomic
>operation is one that cannot be observed, or interfered with, "half
>done".
>>This has lots of uses with databases, and is a major requirement there
>(and a basic database book will probably explain it better than I), but
>it's a big thing when you're designing an SMP/preemptive/preemptible
>kernel, too. :)
>
>Hope I was enlightening and not just boring
>--hobbs
Same here. Thank you For giving me something more than a link
It's all the different angles that makes this comprehensible
to me.
=====================================================================
jw schultz <[email protected]> wrote
>In programming we describe as atomic any action that cannot
>be split (a read(2) from a serial device cannot return just 3
>bits) or an action containing multiple sub-actions that if
>split/interrupted causes breakage. If you interrupt an
>atomic_* it will set of a chain reaction and the OS will
>explode :)
>
Thanks, this is what made the choice of "atomic_" seem as
a clear choice in Unix words (in a post WW2 perspective).
Jesse Pollard <[email protected]> wrote
>This reference has to do with operations that must be completed
>against memory WITHOUT any intervening accesses. The reference "atomic_"
>comes from "non-divisible" operations where the operation cannot
>or must not be subdivided any further (also from physics where atoms
>cannot normally be subdivided).
-[snip]-
Thank you VERY much Jesse!
Your very nice reference will not fit here. It is quite thorough
as well as comprehensive, and must have taken a good bit of time
to write down. I do suppose that there aren't any typos ? Most
of It does make sense to me. Is it published anywhere ?
=================================================================0
=================================================================0
>> Other words in this ML (and in too many other places =( ) that
>> make my own brain go rivetted and short circuit are the "foo"
>> and/or "bar", not to mention the "foobar" place holder.
>>
>> I realize that most folks In LKML use "foo", "bar" and it's dad,
>> "foobar" with outmost joy and that there is complete and utter
>> understanding of what the "foos" and "bars" actually stand for
>> in your contemporary discussion partners reasoning scheeme.
>>
>> Or is it?
Albert D. Cahalan <[email protected]> wrote
>
>You could use ExampleOne, ExampleTwo, and ExampleThree,
>but the CS convention is foo, bar, and baz.
>
>foo -- the 1st metasyntactic variable
>bar -- the 2nd metasyntactic variable
>baz -- the 3rd metasyntactic variable
Thanks again Albert. Now I know that It is actually a
"CS-convention" =-(
=======================================================
jw schultz <[email protected]> wrote
>
>The terms foo, bar, foobar, sna, etc in psuedocode stand for
>"something having a name" We use them in places where the
>actual name doesn't matter for the sake of the discussion.
This rhimes well with the rest of my answers.
>The "good replacer words" can often be almost-real or
>unintentially real name and cause confusion or divert the
A possible fix for this problem in pseudo - C could be:
// void *good_replacer_word(specified_arg1);
or
/* void *good_replacer_word(specified_arg1) */
>functional discussion into a discussion (argument) over
>names. They are sometimes also used to mean "you make up a
>name that has meaning for your purpose".
Yes do I believe that I have seen this on LKML quite often.
>________________________________________________________________
> J.W. Schultz Pegasystems Technologies
> email address: [email protected]
===========================================================
From: Thunder from the hill <[email protected]>
>Well, there's indeed a meaning behind it, apart from "fucked over and over
>beyond all repair."
Hi thunder.
Thanks for taking time with me. Yes maybe you have
written some of the linux jargon file at tuxedo.org ?
;)
==========================================================================
Jesse Pollard <[email protected]> wrote
>ie:
> void *foobar()
>
>would mean "a function returning a pointer to a void type" where the actual
>NAME of the function is not really relevent to the topic. This can be carried
>to connect things like the above together as a form of prototype specification,
>used only in describing the prototype, and is not the prototype itself.
>
>No, it isn't 100% accurate. And it is easily misunderstood, especially if
>english (the US style) is mixed with the (British syle) and mixed with
>non-english transliterations of other idiomatic language structures.
How "fruchtbar"!
;)
>But it means the participants in the discussion LEARN more about communicating
>with others - sometimes emotionally, sometimes with laughter, sometimes just
>a "oh, so that is what you mean...".
Yeah? Well this is rather hard to promote against ..., =-/
but I would feel rather stupid if I was to try and debug
other peoples "fubars" at the level I am now anyway..
I often notice angry reactions. like
"I'm not going to try and read your buggy peace of crap again"
Is that what you call "emotional" ?
>Sometimes it may take a little longer to get to a solution, but it seems to
>be more fun, and the result is usually much better than what happens in more
>regimented organizations.
But don't you sort of get tired of it ?
>-------------------------------------------------------------------------
>Jesse I Pollard, II
>Email: [email protected]
>
>Any opinions expressed are solely my own.
Same here.
Kevin Buhr <[email protected]> wrote
>This has been explained by others, but let me note that the Jargon
>File is an excellent resource for these types of questions:
>
> http://www.tuxedo.org/~esr/jargon/
Yes It was, but as I pointed out above, It is the different angles
that makes me comprehend. Thanks again for the link. I think
that this dictionary will be of great value.
But It doesn't contain the word "alienate" though ;)
>
>By definition, "foo"s and "bar"s are ambiguous. That's why they
>should be used sparingly. Typically they're used in little examples
>of shell or C code where you need a *name*, but it's exact value and
>meaning aren't important, like so:
>>> Hey, there's a bug in the kernel! Do "ln -s foo foo; mkdir foo"
>>> and watch the fireworks.
>
>They're rarely used to talk about new data structures except at the
>earliest speculative design state.
Isn't the earliest speculative design state rather crucial
for a mutual understanding?
We seem to agree somewhat here at least?
=)
>--
>Kevin Buhr <[email protected]>
>
Kind regards. and thanks again everybody.
Daniel Mose
Hi,
On Fri, 26 Jul 2002 [email protected] wrote:
> DEC also used fubar to refer to the Failed UniBus Access Register on a
> VAX, but I think that was either a backronym, or thought up by somebody
> who wasn't already aware of the other meaning.
I never said it was none.
Thunder
On Fri, 19 Jul 2002, Jesse Pollard wrote:
[snip]
> In even earlier OSs (DEC RSX, TOPS 10) the file index table was actually a file
> in the filesystem (usually named index.idx (or was it file.idx...).
INDEXF.SYS, on TOPS-10.
> I don't
> know what it was called in MULTICs where the UNIX varient would have
> started.
>
> Most of these filesystems were based on contigeuous allocation, or allocations
> of contigeous segments.
"Extents". "Segments" were contiguous hunks of real memory that the MMU
knew about, then as now.
TOPS-20 used pagemaps. A file on disk had a pagemap block filled with
special invalid PTEs which pointed to the data blocks. To open a file,
locate its pagemap and page that in, then make references through it and
the pager will pull in the data for you and update the map page. (This is
all separate from mapping a file over *process* virtual memory, but I seem
to recall that PMAP% borrowed a lot of code from the disk I/O subsystem in
this case. It's been 20 years, though....) TOPS-20 happily scattered
file blocks all over the volume-set if need be.
[snip]
> Note - the version number had nothing to do with the file version -
> it was used to aid file recovery and was only a reuse count of the index
> node. The index node contents had to have the same version number as the
> directory entry, or the directory entry was considered invalid. The
> file name was a rad50, or sixbit (packed) characters, and sometimes was
> stored in both inode and directory - again, for rebuilding the file system.
No, RAD50 and SIXBIT are different. You can (de)compose SIXBIT words with
simple shift-and-mask operations, but RAD50 requires arithmetic. (Hmmm,
on TOPS-10 we called it RADIX50, so maybe it's different.)
--
Mark H. Wood, Lead System Programmer [email protected]
Who just last weekend rediscovered an MF10 core-plane hiding in the filing
cabinet.
--------- Received message begins Here ---------
>
> On Fri, 19 Jul 2002, Jesse Pollard wrote:
> [snip]
> > In even earlier OSs (DEC RSX, TOPS 10) the file index table was actually a file
> > in the filesystem (usually named index.idx (or was it file.idx...).
>
> INDEXF.SYS, on TOPS-10.
>
> > I don't
> > know what it was called in MULTICs where the UNIX varient would have
> > started.
> >
> > Most of these filesystems were based on contigeuous allocation, or allocations
> > of contigeous segments.
>
> "Extents". "Segments" were contiguous hunks of real memory that the MMU
> knew about, then as now.
I'll accept extents - the "segment" reference was wrong.
> [snip]
> > Note - the version number had nothing to do with the file version -
> > it was used to aid file recovery and was only a reuse count of the index
> > node. The index node contents had to have the same version number as the
> > directory entry, or the directory entry was considered invalid. The
> > file name was a rad50, or sixbit (packed) characters, and sometimes was
> > stored in both inode and directory - again, for rebuilding the file system.
>
> No, RAD50 and SIXBIT are different. You can (de)compose SIXBIT words with
> simple shift-and-mask operations, but RAD50 requires arithmetic. (Hmmm,
> on TOPS-10 we called it RADIX50, so maybe it's different.)
Definitely different. RAD50 was used in FILES-11 and RT-11 disks. It was used
to store 3 characters in a 16 bit word. SIXBIT was used on TOPS-10 36bit
systems to store 6 characters in a word. It also allowed for a fast file
name search since the names were all on word boundaries (full filename
compair took 2 compair, and 1 mask operation 6+3 file names).
> --
> Mark H. Wood, Lead System Programmer [email protected]
> Who just last weekend rediscovered an MF10 core-plane hiding in the filing
> cabinet.
Still got the manuals ? :-)
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
Hi!
I don't know if the mystery has been solved yet, since I didn't follow the
whole thread, but...
DeepThought ~ # man df
[...]
-i, --inodes
List inode usage information instead of block
usage. An inode (short for index node) contains
information about a file such as its owner, permis-
sions, timestamps, and location on the disk.
[...]
:-)
Regards,
Gert