From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Logan Subject: Re: Passing ioctls between front-end and back-end drivers Date: Mon, 21 Nov 2005 17:24:07 +0000 Message-ID: <438202B7.4060001@symantec.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Pratt Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Ah, that explains why I couldn't find out how to do it. The ioctl's that I am thinking of are vendor specific. I'm looking at supporting devices in Dom0 that can be accessed from the guest domains and part of the driver functionality requires ioctls to get/set attributes etc. It would be up to the backend to determine if the ioctls were valid or not. I agree that this is rather Linux/Unix specific but in my case it's a fundamental part of the driver. Maybe some of the attributes can be passed via Xenstore, I'll investigate. Nick Ian Pratt wrote: >>I see that the block driver supports requests for READ, WRITE >>and PROBE. >>Is there any recommended way to pass ioctl requests from the >>front-end to be executed by the back-end driver? >> >> > >Currently, no. > >Creating a new request operation type that allows the front end to pass >through ioctls would be useful, but it ends up being rather Linux >specific. Further, for security reasons the backend is going to need to >be able to decode the ioctl and decide whether its safe to issue or not. >It would be better to have a 'wire protocol' for this. > >A mechanism for passing scsi commands through would be better, but even >then there are a bunch of vendor-specific ones its not entirely easy to >tell whether they should be allowed by a guest or not. I suspect we need >to draw up a list of what "ioctls" should be allowed. What one do you >want to perform? > >Ian > >