From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Bluetooth options
Date: Sat, 11 Oct 2008 13:06:03 +0100 [thread overview]
Message-ID: <200810111306.13436.paul@codesourcery.com> (raw)
In-Reply-To: <fb249edb0810110418v84eaec2pc18af6f3baea92e5@mail.gmail.com>
> > Do we really need 3 different options? Can't everything be done with a
> > single -bt option, like it is with -net?
>
> We can and then the syntax is more like with -net and less like with
> -usbdevice, the attached patch does that instead.
This looks better to me.
> The syntax is now:
> -bt hci,null
> -bt hci,host[:id]
Shouldn't these also have vlan arguments?
> -bt hci[,vlan=N]
> -bt vhci[,vlan=N]
> -bt device:dev[,vlan=N]
I think you're being somewhat inconsistent about the option syntax. Using -bt
hci for null/"standard" emulated HCI and host hci passthrough but not vhci is
particularly unintuitive.
The device: qualifier seems like it should be redundant. Unlike USB which is a
single master bus, bluetooth network topology is peer-peer with master/slave
roles being negotiated on a per-connection basis.
Is there any point having a "null" HCI?
I'd expect something along the lines of:
-bt null[...]
-bt hci[...]
-bt vhci[...]
-bt host[,id=N][...]
-bt sdp[...]
Obviously this all needs documentation before it is committed ;-)
I'm a little confused what the point of the null hci is. Is this a hci that
isn't connected to anything else, in which case how is it different to a
default hci without anything else on the scatternet. Or is it a dummy test
device that just rejects all connections attempts, in which case calling it a
HCI seems misleading.
> > I'd kinda expect serial bluetooth dongles to be added the same way as USB
> > ones, i.e. via -serial options.
>
> The serial dongle emulated in hw/bt-hci-csr.c has some vendor
> extensions so it's not a standard serial dongle. It's attached by the
> machine code because this part is not configurable in n8x0. One can
> add support for attaching hot-pluggable serial dongles in vl.c if
> needed.
That sounds like an n8x0 bug. I'm not requiring it be fixed now, but it feels
like something that should go away.
Paul
next prev parent reply other threads:[~2008-10-11 12:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-29 1:27 [Qemu-devel] Bluetooth options andrzej zaborowski
2008-09-29 10:54 ` Paul Brook
2008-10-11 11:18 ` andrzej zaborowski
2008-10-11 12:06 ` Paul Brook [this message]
2008-10-11 12:51 ` andrzej zaborowski
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=200810111306.13436.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
/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.