All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Riley <rileyrd@purdue.edu>
To: Jian Wang <jeans.wang@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: how to make xenbus do .probe?
Date: Wed, 07 Mar 2007 13:03:30 -0500	[thread overview]
Message-ID: <45EEFE72.6020707@purdue.edu> (raw)
In-Reply-To: <f8c101b70703061835j4c7572a0g88adaded454dfd5b@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2628 bytes --]

Attached you'll find a simple bash script illustrating how to get both 
the backend and frontend of the skeleton driver to fire.

Here's how to use it:
-Startup a Xen guest that contains your frontend driver, and be sure 
dom0 contains the backend driver.
-Figure out the frontend-id for the guest.  (I only have one guest so, 
the frontend-id is the number on the first line of `xenstore-ls 
/local/domain/0/backend/vbd`).  Let's pretend that number is 3.
-Run the script as so:  ./probetest.sh mydevice 3

That should fire both probes.

The only tricky things about the script are writing the states in the 
right order and changing the permissions of one of the xenstore keys.

Thanks
Ryan

Jian Wang wrote:
> It really works for backend!!
> Thanks a lot.
> But seems frontend .probe still not got called.
> Could you tell me how to adjust the parameter to make the frontend do 
> probe?
> -Jian
>
>
> On 3/6/07, Ryan Riley <rileyrd@purdue.edu> wrote:
>> Yeah, the wiki page you refer to in a later message is incorrect, but I
>> think that the major thing wrong with it is the xenstore-write commands.
>> (At the moment I don't have time to check whether the skeleton driver
>> code is correct, and I can't remember if I had to tweak it when I went
>> through what you're going through.)
>>
>> Here's 4 xenstore-write commands that should get a probe out of the 
>> device:
>>
>> xenstore-write /local/domain/5/device/mydevice/0/state 1
>>
>> xenstore-write /local/domain/0/backend/mydevice/5/0/frontend-id 5
>>
>> xenstore-write /local/domain/0/backend/mydevice/5/0/frontend
>> /local/domain/5/device/mydevice/0
>>
>> xenstore-write /local/domain/0/backend/mydevice/5/0/state 1
>>
>> Quick note: That will only work once per boot, because once the driver
>> is probed with frontend-id 5 the xenbus code seems to be smart enough to
>> not do it again.  If you need to make another probe happen during the
>> same boot, just increment the 5 all around.  I hope this helps.
>>
>> Thanks
>> Ryan
>>
>> Jian Wang <jeans.wang@gmail.com> wrote:
>> >    Hi,
>> >    Can anyone please tell me how to get  ".probe" function in "struct
>> >    xenbus_driver" called?
>> >    I want to do one simple test of  event channel communication 
>> between
>> >    peer modules of
>> >    domU and dom0.
>> >    I wrote one backend and one frontend driver (I tried registered as
>> >    misc/blk/input device) where I put in all my xenbus routines, but
>> >    cannot get .probe called after  insmod my module, I have put
>> >    one week's time to try to find the answer,  failed.
>> >
>> >    Thanks a lot!
>> >    -Jian
>> >
>> >
>>
>>
>>


[-- Attachment #2: probetest.sh --]
[-- Type: text/plain, Size: 995 bytes --]

#!/bin/bash

if [ $# != 2 ]
then
	echo "Usage: $0 <device name> <frontend-id>"
else
	# Write backend information into the location the frontend will look 
	# for it.
	xenstore-write /local/domain/${2}/device/${1}/0/backend-id 0
	xenstore-write /local/domain/${2}/device/${1}/0/backend \
		       /local/domain/0/backend/${1}/${2}/0

	# Write frontend information into the location the backend will look 
	# for it.
	xenstore-write /local/domain/0/backend/${1}/${2}/0/frontend-id ${2}
	xenstore-write /local/domain/0/backend/${1}/${2}/0/frontend \
		       /local/domain/${2}/device/${1}/0

	# Set the permissions on the backend so that the frontend can 
	# actually read it.
	xenstore-chmod /local/domain/0/backend/${1}/${2}/0 r

	# Write the states.  Note that the backend state must be written 
	# last because it requires a valid frontend state to already be 
	# written.
	xenstore-write /local/domain/${2}/device/${1}/0/state 1
	xenstore-write /local/domain/0/backend/${1}/${2}/0/state 1
fi

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

  parent reply	other threads:[~2007-03-07 18:03 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <45EDC042.8090003@purdue.edu>
2007-03-06 19:31 ` how to make xenbus do .probe? Ryan Riley
     [not found]   ` <f8c101b70703061835j4c7572a0g88adaded454dfd5b@mail.gmail.com>
2007-03-07 18:03     ` Ryan Riley [this message]
2007-02-28 23:32 Jian Wang
2007-03-05 18:27 ` Jian Wang
2007-03-05 19:23   ` Jian Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45EEFE72.6020707@purdue.edu \
    --to=rileyrd@purdue.edu \
    --cc=jeans.wang@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.