El 23/09/15 a les 23:56, Olaf Buddenhagen ha escrit:
On Sat, Sep 19, 2015 at 10:52:01AM +0200, Robert Millan wrote:
So if you wanted Sun audio, then yes it's a 1:1 wrapper. Otherwise you
have to convert.
That's a bummer. I was assuming that all BSDs -- and by extension, Rump
-- use OSS...
It
On 23/09/15 21:49, Olaf Buddenhagen wrote:
IMO the right way to do device drivers in a hosted environment is to
have one entity which decides which servers see which devices and just
let the servers attach to all devices they see.
From what I gathered from Robert's and your explanations, it so
Hi,
On Sat, Sep 19, 2015 at 01:24:17PM +, Antti Kantee wrote:
> IMO the right way to do device drivers in a hosted environment is to
> have one entity which decides which servers see which devices and just
> let the servers attach to all devices they see.
>From what I gathered from Robert's
Hi,
On Sat, Sep 19, 2015 at 10:52:01AM +0200, Robert Millan wrote:
> El 19/09/15 a les 01:06, Olaf Buddenhagen ha escrit:
> >Is there any actual logic that could be split out into the audio and
> >mixer translators?
[...]
> That depends on the sound API you want to provide to applications.
>
> R
On 19/09/15 08:52, Robert Millan wrote:
[Adding rumpkernel-users]
El 19/09/15 a les 01:21, Olaf Buddenhagen ha escrit:
Is there no way to limit the probing to a particular device, though? In
the long run, it really seems cleaner to tell the driver, "please try to
serve this device", rather tha
Olaf Buddenhagen, le Sat 19 Sep 2015 01:16:13 +0200, a écrit :
> On Thu, Sep 17, 2015 at 05:35:28PM +0200, Samuel Thibault wrote:
>
> > For me, the idea could be that you run a rump translator per PCI device,
> > which exposes devices appropriately. We'd need a common PCI translator
> > to multipl
[Adding rumpkernel-users]
El 19/09/15 a les 01:21, Olaf Buddenhagen ha escrit:
Is there no way to limit the probing to a particular device, though? In
the long run, it really seems cleaner to tell the driver, "please try to
serve this device", rather than "go out and see whether you can find an
El 19/09/15 a les 01:06, Olaf Buddenhagen ha escrit:
This could work -- but I'm not sure it would be very useful? Is there
any actual logic that could be split out into the audio and mixer
translators? My suspicion is that they would rather just be
straightforward wrappers -- in which case it see
you don't want to start a
> > different Rump instance for /dev/audio, /dev/mixer, etc as they would fight
> > each other trying to access the same hardware).
[...]
> What comes to mind, is that a translator can serve a directory and the
> nodes inside it. The console does it, II
Hi,
On Thu, Sep 17, 2015 at 12:25:21PM -0300, Diego Nieto Cid wrote:
> Another alternative, I was considering while going back home from work, is
> to design this in layers. As in the following graph:
>
> ++
> | Applications |
> +
Hi,
On Thu, Sep 17, 2015 at 05:35:28PM +0200, Samuel Thibault wrote:
> For me, the idea could be that you run a rump translator per PCI device,
> which exposes devices appropriately. We'd need a common PCI translator
> to multiplex accesses to the config space, but otherwise working on
> a PCI de
Hi,
On Thu, Sep 17, 2015 at 09:55:32PM +0200, Robert Millan wrote:
> El 17/09/15 a les 17:35, Samuel Thibault ha escrit:
> >For me, the idea could be that you run a rump translator per PCI
> >device,
>
> That doesn't fit very well with the way Rump works. With Rump you
> select drivers rather th
12 matches
Mail list logo
