On 26 Mar 2002, at 11:47, Alex Rousskov <rousskov@measurement-factory.com> wrote:
> > > Would be nice to have in 2.6. I have one implementation
> > > for that, based on recursive configfile parser. recursion
> > > loops are detected by remembering inodes of seen configs.
>
> Inodes?! Would not file name be sufficient?
When I wrote it, I thought that people would start using symbolic
links left and right, so there is a need to identify unique files,
not links. Inodes provide this. They make it possible to trap
exact file that is creating a loop even if many links point to it.
I wanted to detect exact moment when loop is created. Besides
inodes are alot easier to "remember" and compare ;). For names,
you'd need to deal with typical cases like "../squid/etc/file.cfg"
and later "etc/file.cfg". Comparing these equal is alot of bother.
Probably it would be initially simpler to just count recursion
depth and limit it to something as Henrik suggested. It would
only provide very little help when nonobvious loop is created,
we can't pinpoint the faulty #include, but this might be a
nonissue. Probably portability outweights that too.
But with recursion limit, you are immediately to ask what is
the good depth limit? 2-4,16? Or number of #include directives?
Limit would not detect multiple includes of the same file which
might cause headache for some fancy people. Not our problem
strictly, but depending on case this might cause very difficult
to diagnose situations which may lead to blaming bugs in squid.
Also, another issue arrives when adding notion of #includes: what
is a correct action when #include file is not accessible? Some
includes are critical for correct operation, some are not, should
we bail out or continue? Perhaps create #include and #required?
I tend to wish that we could ignore #include errors, this would
make it possible to include configs from files on swap disks if
they are mounted, thinking of hotswap disks or netmounts.
> > > I don't consider recursion here as evil, besides it makes
> > > for pretty simple patch.
>
> I agree that it is not evil, but using up all RAM at start-up for no
> obvious reason can be annoying, especially if it is a result of a
> minor typo made in a perfectly fine and used-to-work file. In my
> experience, once you let people use #includes, some will create very
> complicated cfg file hierarchies.
Right, so some sort of loop detection must be in place.
------------------------------------
Andres Kroonmaa <andre@online.ee>
CTO, Microlink Online
Tel: 6501 731, Fax: 6501 725
Pärnu mnt. 158, Tallinn,
11317 Estonia
Received on Mon Apr 01 2002 - 00:25:33 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:55 MST