* libxc linux privcmd bugs
@ 2014-01-13 16:53 Andrew Cooper
2014-01-13 17:06 ` Ian Campbell
2014-01-13 17:06 ` Ian Campbell
0 siblings, 2 replies; 4+ messages in thread
From: Andrew Cooper @ 2014-01-13 16:53 UTC (permalink / raw)
To: Xen-devel List, Ian Campbell
Hello,
More bugs for tracking:
1) PERROR("Could not obtain handle on privileged command interface");
doesn't indicate which path(s) were tried.
2) xc_linux_osdep.c:linux_privcmd_open() only tries to open
"/proc/xen/privcmd" which is the classic-xen location, whereas the
expected location under PVops is "/dev/xen/privcmd". The other open
functions (evtchn, gnttab, gntshr) exclusivly use "/dev/xen/$FOO".
~Andrew
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: libxc linux privcmd bugs
2014-01-13 16:53 libxc linux privcmd bugs Andrew Cooper
@ 2014-01-13 17:06 ` Ian Campbell
2014-01-13 17:06 ` Ian Campbell
1 sibling, 0 replies; 4+ messages in thread
From: Ian Campbell @ 2014-01-13 17:06 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel List
create ^
title it libxc should use /dev/xen/privcmd on Linux
severity it wishlist
thanks
On Mon, 2014-01-13 at 16:53 +0000, Andrew Cooper wrote:
> Hello,
>
> More bugs for tracking:
>
> 1) PERROR("Could not obtain handle on privileged command interface");
> doesn't indicate which path(s) were tried.
>
> 2) xc_linux_osdep.c:linux_privcmd_open() only tries to open
> "/proc/xen/privcmd" which is the classic-xen location, whereas the
> expected location under PVops is "/dev/xen/privcmd".
Nothing has ever used /dev/xen/privcmd since it was reimplemented to
replace xenfs, so describing it as expected is a bit strong. At best
there is a wishlist issue here for someone to finish implementing this
transition, which I've now created.
http://lists.xen.org/archives/html/xen-devel/2011-12/msg01344.html
http://lists.xen.org/archives/html/xen-devel/2011-12/msg01345.html
looks to be related patches, not sure why thay didn't go in back then.
Lack of a S-o-b perhaps.
> The other open
> functions (evtchn, gnttab, gntshr) exclusivly use "/dev/xen/$FOO".
These have only ever been driver rather than proc based so there was
never a transition.
Ian.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: libxc linux privcmd bugs
2014-01-13 16:53 libxc linux privcmd bugs Andrew Cooper
2014-01-13 17:06 ` Ian Campbell
@ 2014-01-13 17:06 ` Ian Campbell
2014-01-13 17:15 ` Processed: " xen
1 sibling, 1 reply; 4+ messages in thread
From: Ian Campbell @ 2014-01-13 17:06 UTC (permalink / raw)
To: Andrew Cooper; +Cc: Xen-devel List
create ^
title it libxc should use /dev/xen/privcmd on Linux
severity it wishlist
thanks
On Mon, 2014-01-13 at 16:53 +0000, Andrew Cooper wrote:
> Hello,
>
> More bugs for tracking:
>
> 1) PERROR("Could not obtain handle on privileged command interface");
> doesn't indicate which path(s) were tried.
>
> 2) xc_linux_osdep.c:linux_privcmd_open() only tries to open
> "/proc/xen/privcmd" which is the classic-xen location, whereas the
> expected location under PVops is "/dev/xen/privcmd".
Nothing has ever used /dev/xen/privcmd since it was reimplemented to
replace xenfs, so describing it as expected is a bit strong. At best
there is a wishlist issue here for someone to finish implementing this
transition, which I've now created.
http://lists.xen.org/archives/html/xen-devel/2011-12/msg01344.html
http://lists.xen.org/archives/html/xen-devel/2011-12/msg01345.html
looks to be related patches, not sure why thay didn't go in back then.
Lack of a S-o-b perhaps.
> The other open
> functions (evtchn, gnttab, gntshr) exclusivly use "/dev/xen/$FOO".
These have only ever been driver rather than proc based so there was
never a transition.
Ian.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-01-13 17:15 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-13 16:53 libxc linux privcmd bugs Andrew Cooper
2014-01-13 17:06 ` Ian Campbell
2014-01-13 17:06 ` Ian Campbell
2014-01-13 17:15 ` Processed: " xen
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.