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

[Marek Vasut]

Dear Pavel Herrmann,

> 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"?

Ok, I'd like to get it reviewed by someone else and then I think it can be 
applied.

Mike?

> > I think we're almost clear on these things.
> 
> thats a relief
> 
> Pavel Herrmann

Best regards,
Marek Vasut