[U-Boot] [PATCH] Loop block device for sandbox

[Pavel Herrmann <morpheus.ibis@gmail.com>]

On Friday 31 of August 2012 18:02:22 Marek Vasut wrote:
> > > > > > > > > > +	memcpy(pdev->product, filenames[dev], namelen);
> > > > > > > > > > +	pdev->product[20] = 0;
> > > > > > > > > > +
> > > > > > > > > > +	if (fd != -1) {
> > > > > > > > > 
> > > > > > > > > And if "fd" is -1 ?
> > > > > > > > 
> > > > > > > > then all defaults to an invalid device, because you failed to
> > > > > > > > open the file, for whatever the reason.
> > > > > > > 
> > > > > > > At least the printf below will choke, since pdev->lba is
> > > > > > > uninited
> > > > > > 
> > > > > > not the case. sata_dev_desc is inited in cmd_sata.c, and therefore
> > > > > > by not doing anything we get an empty device
> > > > > 
> > > > > I see ... shall we also move all these memcpy() calls in to if (fd
> > > > > !=
> > > > > -1)
> > > > > then?
> > > > 
> > > > I'd like to know that the device is a loopback, and what filename, not
> > > > just
> > > > that it failed to init
> > > 
> > > But are such data used somewhere further down the road?
> > 
> > yes, "sata info" for example
> 
> And how does it determine that the init failed?

given that the only thing the init does is open a file and put the decriptor to 
->priv, you can tell whether it failed by looking at the descriptor (-1 means 
failed). the other fail-path in init is if it is given a wrong index, but that 
should never happen (at least not when called from cmd_sata)

on a disk with 0 size you cant have a partition table, so any FS code will 
refuse to work, any direct operation will fail because fd is -1

or did you mean a different "it"?

> I think we're almost clear on these things.

thats a relief
 
Pavel Herrmann