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

Pavel Herrmann
2012-08-31T17:56:02Z

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