RE: [rfa] Add the bfd_iovec

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: binutils-owner On Behalf Of Andrew Cagney
> Sent: 16 April 2004 18:28

> >   From my reading of your code, you seem to have removed the caching
> > functionality from the bfd layer and moved it into a 
> specialized iovec.
> 
> Only one IOVEC required the mechanism, and there, for a very 
> specalized 
> reason (as you note) - a shortage of file descriptors.  By 
> moving that 
> complexity into the FILE IOVEC, BFD proper was simplified.
> 
> When it turns out that a generalized FD-cache mechanism is 
> needed then, 
> the person needing the mechanism can add it :-) (at present 
> we've only 
> memory, FILE and GDB-inferior IOVECs and only FILE has the problems).

  That sounds completely reasonable then.  I wasn't aware how specialized it
was, I thought it might be more globally applicable.

> Anyway, and regardless, I think that such a mechanism belongs in the 
> lower layers (IOVEC) and should not be directly tied to BFD.  
> By keeping 
> it separate from BFD clients (i.e., GDB) use the underlying 
> FD-cache to 
> manage other open files - the source code.

  Erm... that only makes sense to me if you're planning to rewrite gdb to
use an iovec layer for its own (non-bfd) file access.... should I infer that
you are, or at any rate that you want it to be an option for the future?

> ISTM?

  It Seems To Me.

> As you note, each has advantages and disadvantages.  Where 
> the interface 
> external I'd have done what you suggest.  It isn't so I made it as 
> simple and sparse as possible.

  That's also a reasonable decision; I'm slightly worried, because in things
like gcc and gdb you tend to have target vectors where you *do* leave a NULL
in the pointer for an unimplemented function, and people might assume it
works the same way.  I guess that's something you could take care of simply
by documenting the requirement.

> Also, one of the long ago original threads expressed concern 
> at the call 
> overhead (Ok I don't be believe it to be significant), but hey this 
> looks leaner :-)

  Well, looking lean isn't very important compared to code correctness!  I'd
say the same applies even when you're adding a NULL test in the wrapper
layer.  Of course there could always be accessor macros that define to check
or not check according to configure-time options.

> >   Isn't it likely to break something if you check this in 
> without doing so? 
> 
> I'm lost.  It's the memmory code, that's going to need many changes.

  Yes, sorry, as I mentioned in my followup post, I didn't re-read the
thread until after I made the post, and came across your explanation that
the fixes to the memory code would be in a follow-on patch.

  Anyway, that certainly addresses all my concerns and curiosities.  Thanks
for taking the time to explain.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....