From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Andries.Brouwer@cwi.nl, Alexander Viro <viro@math.psu.edu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH+discussion] symlink recursion
Date: Wed, 19 Jun 2002 13:48:17 +0200 (MEST) [thread overview]
Message-ID: <200206191148.NAA06237@cave.bitwizard.nl> (raw)
In-Reply-To: <Pine.LNX.4.33.0206181646220.2562-100000@penguin.transmeta.com> from Linus Torvalds at "Jun 18, 2002 04:57:06 pm"
Linus Torvalds wrote:
> Could we allow deeper recursion if we did it by hand? Sure. Are
> there any real advantages in 15 levels of recursion over 5 levels of
> recursion? I don't see any.
I'm working on a system that stores part of the "how the hardware is
wired" in symlinks in the filesystem. Funny concept, but it allows us
to view the state of the system with standard filesystem tools.
So we have
Exhaust_pump -> DIO2/o/13
This tells us that the Exhaust_pump is connected on pin 13 of the
outputs on the module called "DIO2". Now DIO2 is a (digital IO) module
of type "dio" and it's the third on the bus.....
DIO2 -> dio/3
Pin 13 on that module is simply a bit belonging to a word in my
"iospace" (the pin numbers are not the same as the bit numbers in from
the software viewpoint):
dio/3/o/13 -> ../../bits/45/1 (*)
So in this example I seem to be using 3 symlinks in one path. I know
I've run into the "5" limit at sometime in the past. Probably because
this directory was linked somewhere, and that was moved and
compatibility-linked again. And/or there may be one or more extra
levels of indirections in the links in my devices directory.
Linus, people are using symlinks for different stuff than you
are. Thus they have slightly different "boundary conditions". 5
symlinks is just too little. It's "too close for comfort".
Something like: "symlinks can't nest more than 15 levels deep, but may
never cause the pathname to exceed XX chars" is a reasonable limit.
Now doing that "recursively" may mean that the stack grows too
large. If that's the case, then I'm in favor of going for the
iterative approach.
Roger.
(*) Don't pin me on the number of "../" items in this link: It was
difficult enough the first time around, with the shell constantly
trying to outsmart me.....
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2137555 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* There are old pilots, and there are bold pilots.
* There are also old, bald pilots.
next prev parent reply other threads:[~2002-06-19 11:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-18 22:19 [PATCH+discussion] symlink recursion Andries.Brouwer
2002-06-18 23:57 ` Linus Torvalds
2002-06-19 7:12 ` William Lee Irwin III
2002-06-19 11:48 ` Rogier Wolff [this message]
2002-06-19 14:44 ` Daniel Phillips
2002-06-19 16:05 ` Linus Torvalds
2002-06-19 18:18 ` Andries Brouwer
2002-06-19 18:55 ` Linus Torvalds
2002-06-19 19:14 ` David Mosberger
2002-06-19 22:06 ` David S. Miller
-- strict thread matches above, loose matches on Subject: below --
2002-06-19 7:02 Andries.Brouwer
2002-06-19 20:01 Andries.Brouwer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200206191148.NAA06237@cave.bitwizard.nl \
--to=r.e.wolff@bitwizard.nl \
--cc=Andries.Brouwer@cwi.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=viro@math.psu.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.