Comment # 17
on bug 8589
from Dominique Martinet
(In reply to comment #16)
> Checked in (after pulling the contents of the new header file back into the
> .c file--we try to only use header files for sharing information between
> modules), thanks for the contribution!
>
> BTW I found that there is a 9P sample capture on the SampleCaptures page on
> the wiki; it does appear your patch didn't break anything.
OK and good! Thanks for having it.
> (In reply to comment #0)
> > It is probably not good as it is, given it assumes packets are dissected
> > once (and only once) in the stream order, which is not the correct. Any hint
> > there is welcome.
>
> I noticed this comment but I'm not sure what to make of it. If you want to
> know how to avoid doing something any time except on the first pass you can
> look at pinfo->fd->flags.visited (it's set to 0 on the first
> pass/dissection--when tree is NULL but frames are all dissected in
> order--and 1 on subsequent passes/dissections).
Ooh, that's good to know.
The problem with my current approach is that if you look at packets out of
order (skip pages, come back up, etc) the "fid" path string will be wrong,
because it's a stateful information that changes along with the stream.
With this I could compute the fid tree only on first pass, adding some info
like "valid between pinfo->fd->num X and Y", and look that up on further
passes.
Would it be acceptable to rely on frame data number for this?
Will also probably make things a bit slower, if we want to pay the price for
displaying accurate data (the naive version would mean iterating through the
whole filename table on insertion if we want to re-use already allocated
strings, and iterating through all possible fids looking for a matching frame
data number on display... I'll try to think it through)
Last silly question, is there anywhere better than a fixed/resolved ticket to
discuss this? ;)
You are receiving this mail because:
- You are watching all bug changes.
