Am 11.08.2011 18:28, schrieb Corey Bryant:
On 07/26/2011 08:51 AM, Corey Bryant wrote:
> +static int raw_open_fd(BlockDriverState *bs, const char *filename,
int flags)
> +{
> + BDRVRawState *s = bs->opaque;
> + const char *fd_str;
> + int fd;
> +
> + /* extract the file descriptor - fail if it's not fd: */
> + if (!strstart(filename, "fd:",&fd_str)) {
> + return -EINVAL;
> + }
> +
> + if (!qemu_isdigit(fd_str[0])) {
> + /* get fd from monitor */
> + fd = qemu_get_fd(fd_str);
> + if (fd == -1) {
> + return -EBADF;
> + }
> + } else {
> + char *endptr = NULL;
> +
> + fd = strtol(fd_str,&endptr, 10);
> + if (*endptr || (fd == 0&& fd_str == endptr)) {
> + return -EBADF;
> + }
> + }
> +
> + s->fd = fd;
> + s->type = FTYPE_FILE;
> +
> + return raw_open_common(bs, filename, flags, 0);
> +}
> +
> +static BlockDriver bdrv_file_fd = {
> + .format_name = "file",
> + .protocol_name = "fd",
> + .instance_size = sizeof(BDRVRawState),
> + .bdrv_probe = NULL, /* no probe for protocols */
> + .bdrv_file_open = raw_open_fd,
> + .bdrv_read = raw_read,
> + .bdrv_write = raw_write,
> + .bdrv_close = raw_close,
> + .bdrv_flush = raw_flush,
> + .bdrv_discard = raw_discard,
> +
> + .bdrv_aio_readv = raw_aio_readv,
> + .bdrv_aio_writev = raw_aio_writev,
> + .bdrv_aio_flush = raw_aio_flush,
> +
> + .bdrv_truncate = raw_truncate,
> + .bdrv_getlength = raw_getlength,
> +
> + .create_options = raw_create_options,
> +};
> +
I'm a bit unsure of how to support CD-ROM with the fd: protocol.
I don't think use of bdrv_file_fd is an option. For example, while
raw_open_fd may work, there is no eject support.
Another approach is to have 2 BlockDriver structs that support the fd
protocol. For example, creating a new BlockDriver struct that mirrors
bdrv_host_cdrom. So you would have bdrv_host_cdrom_fd with a
corresponding cdrom_open_fd function. But that doesn't appear possible
as it appears that the protocol must be unique among all BlockDriver
structs.
Do we need to introduce a similar protocol (maybe "cdfd") to support
passing of CD-ROM file descriptors?
I would try to avoid that. I think you can determine the kind of device
during fd_open and then implement an fd_eject etc. that checks this type
and calls the appropriate ioctl. Maybe the same should be done for
file/host_device/host_cdrom instead of having separate protocols.
Anyway, I don't think this is important to get a first version merged.
It will still take a while anyway until we have full support that
libvirt would want to use.
Kevin