From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH, resend] blkfront: ioctls/geometry, 2.6 Date: Fri, 02 Jun 2006 12:53:55 +0200 Message-ID: <448034E3.76E4.0078.0@novell.com> References: <4480296D.76E4.0078.0@novell.com> <5324398cd809a2cde429589727c53ee5@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5324398cd809a2cde429589727c53ee5@cl.cam.ac.uk> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 02.06.06 12:19 >>> > >On 2 Jun 2006, at 11:05, Jan Beulich wrote: > >> Add backing support for HDIO_GETGEO ioctl to blkfront. >> >> Inspired by an earlier patch from Charles Coffing. > >Does this have any effect? It looks to me as though HDIO_GETGEO is >handled by block/ioctl.c:blkdev_ioctl(). I also note that *no* other >blkdev drivers define their own HDIO_GETGEO handler. Shouldn't we just >remove that case from our ioctl switch statement and define a 'getgeo' >function hook? But that is exactly what the patch does. It instead adds a getgeo function to vbd, which is what several other drivers also have, and which is what backs blkdev_ioctl()'s handling of HDIO_GETGEO. >Given that this patch can't have any effect, what drove you guys to >implement it? :-) We saw GrUB failing when used inside a domU. Jan