Re: [Qemu-devel] [RESEND] [PATCH] ide: fix GET_CONFIGURATION DVD-ROM support

[Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>]

On Sun, Jan 06, 2008 at 01:57:38PM +0000, Stuart Brady wrote:
> On Sat, Jan 05, 2008 at 08:22:33PM -0600, Carlo Marcelo Arenas Belon wrote:
> 
> > the exact number of sectors is really not that relevant, as the whole point
> > here is to try to detect if it is a CD (700MB) or a DVD (4.7GB) and the logic
> > is just assuming that if it has more sectors than you should normally expect
> > in a CD, then it is a DVD.
> 
> My answer was quite relevant to Rob's question, which was "Where does 
> the constant come from, anyway?"

Yes, and my comment didn't meant it wasn't relevant, but that the exact value
isn't as important as finding the upper possible limit that can be used to
assume that anything bigger than that has to be a DVD instead.

when I looked at the patch originally, tried to find something in the
specifications that could be used to define a "standard" CD size but couldn't
find anything, because as other people pointed out, there isn't a "standard"
CD size even if most of the CDs out there are 80min large.

> As for the code, there's a choice between using an incorrect value, and 
> correctly detecting for the vast majority of cases, and using the 
> correct value and correctly detecting for 100% of cases.  Perhaps "only 
> marginally broken" is "good enough", seeing as nobody's complained.

Agree, and that is why I said using 1440000 will be probably better and
provided a tool that can be used to generate this call in the guests (only for
Linux though), so that the maximum value could be found empirically.

Since this is meant to work for ISO images in a file as well as devices with
physical CDs on them, I suspect (and remember the original code which included
this magic value wasn't mine) that the number of sectors might be the only
reliable indication of media size, but will look at it again  and see if there
is any other metadata available in all cases which could be used instead.

> > but I had already enough problems trying to get this
> > merged without trying to change the code that much to try to guess a better
> > magic number than the one was originally used (I like 1440000 though)
> 
> Sorry, but did anyone complain?
> 
> No.

Not sure what you mean by this, but having a patch resent several times with
no comments is IMHO more problematic that complains.

Carlo