On Tue, Jul 26, 2016 at 07:09:41AM +, Dexuan Cui wrote:
> If you meant https://lkml.org/lkml/2016/7/13/382, I don't think Michal
> Kubecek was suggesting I build my code using the existing AF_VSOCK
> code(?) I think he was only asking me to clarify the way I used to write
her than not using the feature) we
are not going to use AF_VSOCK". I would understand if you pointed out
features important for you that are missing in AF_VSOCK but this kind of
reasoning sounds strange to me.
Michal Kubecek
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
sock_create_sock(struct net *net, struct socket *sock,
> + int protocol, int kern)
> +{
> + struct sock *sk;
> +
> + if (!capable(CAP_SYS_ADMIN) && !capable(CAP_NET_ADMIN))
> + return -EPERM;
Looks like any application wanting to use hyper-v sockets will need
rather high privileges. It would make sense if these sockets were
reserved for privileged tasks like VM management. But according to the
commit message, hv_sock is supposed to be used for regular application
to application communication. Requiring CAP_{SYS,NET}_ADMIN looks like
an overkill to me.
> +
> + if (protocol != 0 && protocol != SHV_PROTO_RAW)
> + return -EPROTONOSUPPORT;
> +
> + switch (sock->type) {
> + case SOCK_STREAM:
> + sock->ops = &hvsock_ops;
> + break;
> + default:
> + return -ESOCKTNOSUPPORT;
> + }
> +
> + sock->state = SS_UNCONNECTED;
> +
> + sk = hvsock_create(net, sock, GFP_KERNEL, 0);
> + return sk ? 0 : -ENOMEM;
> +}
Michal Kubecek
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
v->video_limit)
*nbuffers = vpfe_dev->video_limit / size;
instead?
Michal Kubecek
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
