search for: cdev_init

...> + vhost_vdpa.class->devnode = vhost_vdpa_devnode; > > > + > > > + r = alloc_chrdev_region(&vhost_vdpa.devt, 0, MINORMASK + 1, > > > + "vhost-vdpa"); > > > + if (r) > > > + goto err_alloc_chrdev; > > > + > > > + cdev_init(&vhost_vdpa.cdev, &vhost_vdpa_fops); > > > + r = cdev_add(&vhost_vdpa.cdev, vhost_vdpa.devt, MINORMASK + 1); > > > + if (r) > > > + goto err_cdev_add; > > > > It is very strange, is the intention to create a single global char > > dev? >...

...= PTR_ERR(vhost_vdpa.class); > + goto err_class; > + } > + > + vhost_vdpa.class->devnode = vhost_vdpa_devnode; > + > + r = alloc_chrdev_region(&vhost_vdpa.devt, 0, MINORMASK + 1, > + "vhost-vdpa"); > + if (r) > + goto err_alloc_chrdev; > + > + cdev_init(&vhost_vdpa.cdev, &vhost_vdpa_fops); > + r = cdev_add(&vhost_vdpa.cdev, vhost_vdpa.devt, MINORMASK + 1); > + if (r) > + goto err_cdev_add; It is very strange, is the intention to create a single global char dev? If so, why is there this: +static int vhost_vdpa_open(struct i...

...= PTR_ERR(vhost_vdpa.class); > + goto err_class; > + } > + > + vhost_vdpa.class->devnode = vhost_vdpa_devnode; > + > + r = alloc_chrdev_region(&vhost_vdpa.devt, 0, MINORMASK + 1, > + "vhost-vdpa"); > + if (r) > + goto err_alloc_chrdev; > + > + cdev_init(&vhost_vdpa.cdev, &vhost_vdpa_fops); > + r = cdev_add(&vhost_vdpa.cdev, vhost_vdpa.devt, MINORMASK + 1); > + if (r) > + goto err_cdev_add; It is very strange, is the intention to create a single global char dev? If so, why is there this: +static int vhost_vdpa_open(struct i...

...ss; > > + } > > + > > + vhost_vdpa.class->devnode = vhost_vdpa_devnode; > > + > > + r = alloc_chrdev_region(&vhost_vdpa.devt, 0, MINORMASK + 1, > > + "vhost-vdpa"); > > + if (r) > > + goto err_alloc_chrdev; > > + > > + cdev_init(&vhost_vdpa.cdev, &vhost_vdpa_fops); > > + r = cdev_add(&vhost_vdpa.cdev, vhost_vdpa.devt, MINORMASK + 1); > > + if (r) > > + goto err_cdev_add; > > It is very strange, is the intention to create a single global char > dev? No. It's to create a per-vdpa...

...turn -ENODEV on hot-unplug virtio: console: remove_port() should return void virtio: console: open: Use a common path for error handling virtio: console: Add a list of portdevs that are active virtio: console: Add a find_port_by_devt() function virtio: console: Use cdev_alloc() instead of cdev_init() virtio: console: Add reference counting for port struct virtio: console: Reference counting portdev structs is not needed drivers/char/virtio_console.c | 206 ++++++++++++++++++++++++++++++++++------- 1 files changed, 173 insertions(+), 33 deletions(-) -- 1.7.2.2

...turn -ENODEV on hot-unplug virtio: console: remove_port() should return void virtio: console: open: Use a common path for error handling virtio: console: Add a list of portdevs that are active virtio: console: Add a find_port_by_devt() function virtio: console: Use cdev_alloc() instead of cdev_init() virtio: console: Add reference counting for port struct virtio: console: Reference counting portdev structs is not needed drivers/char/virtio_console.c | 206 ++++++++++++++++++++++++++++++++++------- 1 files changed, 173 insertions(+), 33 deletions(-) -- 1.7.2.2

Hello, Here are two patches. One implements a virtio-serial device in qemu and the other is the driver for a guest kernel. While working on a vmchannel interface that is needed for communication between guest userspace and host userspace, I saw that most of the interface can be abstracted out as a "serial" device with "ports". Some requirements for a vmchannel are listed at

Hello, Here are two patches. One implements a virtio-serial device in qemu and the other is the driver for a guest kernel. While working on a vmchannel interface that is needed for communication between guest userspace and host userspace, I saw that most of the interface can be abstracted out as a "serial" device with "ports". Some requirements for a vmchannel are listed at

..._nr); + + port_nr += *map_i * 32; + return port_nr; +} + +static int virtserial_add_port(u32 port_nr) +{ + struct virtio_serial_port *port; + dev_t devt; + int ret; + + port = kzalloc(sizeof(struct virtio_serial_port), GFP_KERNEL); + if (!port) + return -ENOMEM; + + devt = MKDEV(major, port_nr); + cdev_init(&port->cdev, &virtserial_fops); + + ret = register_chrdev_region(devt, 1, "virtio-serial"); + if (ret < 0) { + pr_err("%s: error registering chrdev region, ret = %d\n", + __func__, ret); + goto free_cdev; + } + ret = cdev_add(&port->cdev, devt, 1);...

..._nr); + + port_nr += *map_i * 32; + return port_nr; +} + +static int virtserial_add_port(u32 port_nr) +{ + struct virtio_serial_port *port; + dev_t devt; + int ret; + + port = kzalloc(sizeof(struct virtio_serial_port), GFP_KERNEL); + if (!port) + return -ENOMEM; + + devt = MKDEV(major, port_nr); + cdev_init(&port->cdev, &virtserial_fops); + + ret = register_chrdev_region(devt, 1, "virtio-serial"); + if (ret < 0) { + pr_err("%s: error registering chrdev region, ret = %d\n", + __func__, ret); + goto free_cdev; + } + ret = cdev_add(&port->cdev, devt, 1);...

Hello, This is a new iteration of the patches that implement virtio-serial. Changes include: * Adding support for port hot-add * Creating ports at specific ids that can be bound to specific apps / usage * Cleanups This code still doesn't get rid of the support for assigning names to ports but it just has to be ripped out. Comments welcome. Thanks, Amit.

Hello, This is a new iteration of the patches that implement virtio-serial. Changes include: * Adding support for port hot-add * Creating ports at specific ids that can be bound to specific apps / usage * Cleanups This code still doesn't get rid of the support for assigning names to ports but it just has to be ripped out. Comments welcome. Thanks, Amit.

This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable

This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable

This is the third version of the macvtap device driver, following another major restructuring and a lot of bug fixes: * Change macvtap to be based around a struct sock * macvtap: fix initialization * return 0 to netlink * don't use rcu for q->file and q->vlan pointers * macvtap: checkpatch.pl fixes * macvtap: fix tun IFF flags * Use a struct socket to make tx flow control work * disable

Hello all, This are the latest version of the patches. Lots of things have changed since the last submission. A few of which I remember: - VNC copy / paste works* (* conditions apply) - client vnc copies get propagated to guest port 3 (/dev/vmch3) - guest writes to port 3 (/dev/vmch3) go straight to client's clipboard - sysfs hooks to autodiscover ports - support for 64 ports in this

Hello all, This are the latest version of the patches. Lots of things have changed since the last submission. A few of which I remember: - VNC copy / paste works* (* conditions apply) - client vnc copies get propagated to guest port 3 (/dev/vmch3) - guest writes to port 3 (/dev/vmch3) go straight to client's clipboard - sysfs hooks to autodiscover ports - support for 64 ports in this

I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the

I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the

I did not get this ready for the merge window, but people asked what the status of this is so I'm posting it now to solicit feedback. The first patch just adds some hooks into macvlan.c and is less invasive than the previous version. That part should be fine and I'd like this to get merged into macvlan for 2.6.33 if people agree that the approach is right. The second patch adds the