Re: [RFC] File-I/O, target access to host file system via gdb remote protocol enhancement

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Nov 13, 2002 at 03:51:54PM +0100, Corinna Vinschen wrote:
> On Wed, Nov 13, 2002 at 09:31:40AM -0500, Daniel Jacobowitz wrote:
> > On Wed, Nov 13, 2002 at 02:35:22PM +0100, Corinna Vinschen wrote:
> > > On Tue, Nov 12, 2002 at 04:25:26PM -0500, Daniel Jacobowitz wrote:
> > > > Ick, 32-bit st_ino... why bother to transfer it if you say "no meaning
> > > > for the target"?
> > > 
> > > The point is mainly to have all fields available which a POSIX compliant
> > > application may expect.
> > 
> > Right; but you require that the stub convert to host format anyway, so
> 
> In case of the stat structure it's always gdb which creates/sends the
> structure.  The struct is filled by gdb on behalf of the target OS.
> I'm not aware of a system call which takes a stat struct as input parameter.

Right.  Sorry, I meant "you require the stub to convert _from_ host
format" - isn't that correct?  So if you are explicitly defining the
st_ino field to have a useless value, I don't see why you're sending it
over the wire.  This is a nit; it's not important.

> > it seems odd to send the unused members over the wire.  I guess they
> > might be used someday.
> 
> So you'd change st_ino to 64 bit?

It offends my sense of elegance but I don't see a reason to bother -
not when you've already got a stub using this.  Any application that
relies on a property of st_ino probably wants to have a real filesystem
anyway, right?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer