Hi Bruno,
Quoting Bruno Félix Rezende Ribeiro (2015-09-16 05:47:57)
> I'm interested in USB support. I'd like to aim mass storage devices at
> first.
I'd love to see IDE/SATA drivers as a byproduct or first step of your
work.
Justus
signature.asc
Description: signature
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
Olaf Buddenhagen, le Sat 19 Sep 2015 00:52:08 +0200, a écrit :
> This looks nice for generic USB. I doubt we have a mass storage driver
> using libusb though? Rather, I guess it's something rump implements
> internally, and would be exposed through a different entry point?
I'd say so, yes.
Samuel
Hi,
On Wed, Sep 16, 2015 at 10:12:19PM +, Diego Nieto Cid wrote:
> El mié., 16 sept. 2015 a las 17:57, Robert Millan () escribió:
> > The other problem I had is that I don't know how to make a single
> > translator
> > service two separate device nodes (obviously you don't want to start a
> >
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 Wed, Sep 16, 2015 at 10:57:20PM +0200, Robert Millan wrote:
> El 16/09/15 a les 05:47, Bruno Félix Rezende Ribeiro ha escrit:
> >I'm interested in USB support. I'd like to aim mass storage devices at
> >first.
>
> For USB using Rump, I think most of the pieces exist already. Rump impleme
Hi,
On Fri, Sep 18, 2015 at 09:14:30PM +0200, Robert Millan wrote:
> El 17/09/15 a les 23:25, Samuel Thibault ha escrit:
> >Robert Millan, le Thu 17 Sep 2015 21:55:32 +0200, a écrit :
> >>My understanding is there's no need for an arbiter / multiplexer
> >>as long as all the code playing with PCI
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
Robert Millan, le Fri 18 Sep 2015 21:14:30 +0200, a écrit :
> El 17/09/15 a les 23:25, Samuel Thibault ha escrit:
> >Robert Millan, le Thu 17 Sep 2015 21:55:32 +0200, a écrit :
> >>As for the rest of PCI devices, AFAICT they're free to be used by whoever
> >>wants them. My understanding is there's
El 18/09/15 a les 01:15, Justus Winter ha escrit:
Quoting Robert Millan (2015-09-15 22:11:15)
like, how to service ioctls without libtrivfs?
Is there a reason why you don't want to use libtrivfs?
Not particularly. I just noticed that libtrivfs doesn't implement a stub for
ioctls like it does
El 17/09/15 a les 23:25, Samuel Thibault ha escrit:
Robert Millan, le Thu 17 Sep 2015 21:55:32 +0200, a écrit :
As for the rest of PCI devices, AFAICT they're free to be used by whoever
wants them. My understanding is there's no need for an arbiter / multiplexer
as long as all the code playing w
Quoting Robert Millan (2015-09-15 22:11:15)
> like, how to service ioctls without libtrivfs?
Is there a reason why you don't want to use libtrivfs?
Cheers,
Justus
Robert Millan, le Thu 17 Sep 2015 21:55:32 +0200, a écrit :
> As for the rest of PCI devices, AFAICT they're free to be used by whoever
> wants them. My understanding is there's no need for an arbiter / multiplexer
> as long as all the code playing with PCI devices is well-aware of its limits.
Yes
Hi Samuel,
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 than specific devices. So for example if you start a Rump
instance an
Diego Nieto Cid, le Thu 17 Sep 2015 12:50:10 -0300, a écrit :
> From what he said
>
> > The other problem I had is that I don't know how to make a single translator
> > service two separate device nodes (obviously you don't want to start a
> > different Rump instance for /dev/audio, /dev/mixer, et
2015-09-17 12:35 GMT-03:00 Samuel Thibault :
> Diego Nieto Cid, le Thu 17 Sep 2015 12:25:21 -0300, a écrit :
>> In that way there are several sound related translators separating the
>> concerns
>> while the hardwarde is still accessed by a single translator avoiding the
>> conflicts Robert mentio
Diego Nieto Cid, le Thu 17 Sep 2015 12:25:21 -0300, a écrit :
> In that way there are several sound related translators separating the
> concerns
> while the hardwarde is still accessed by a single translator avoiding the
> conflicts Robert mentioned.
Which conflict?
For me, the idea could be th
2015-09-16 20:06 GMT-03:00 Samuel Thibault :
> Diego Nieto Cid, le Wed 16 Sep 2015 22:12:19 +, a écrit :
>> Except for how to know which one the send right was obtained from in
>> the translator when a message from a client comes?
>
> term is probably easier to have a look at: see the file_set_
Robert Millan, le Tue 15 Sep 2015 22:11:15 +0200, a écrit :
> I was planning to ask for advice on how to make a "/dev/audio -> librump0"
> translator sometime soon. I've written similar a glue layer for Linux [1],
> but I'm missing a lot of knowledge when it comes to the Hurd way of doing
> this (l
Diego Nieto Cid, le Wed 16 Sep 2015 22:12:19 +, a écrit :
> I'm not sure you can service two files with the same translator instance, at
> least with the settrans tool.
You can, see /servers/socket/{2,26} or /dev/[pt]typ0. The trick is to
tell each entry where the other entry is as a command-
Hi
El mié., 16 sept. 2015 a las 17:57, Robert Millan () escribió:
> The other problem I had is that I don't know how to make a single
> translator
> service two separate device nodes (obviously you don't want to start a
> different Rump instance for /dev/audio, /dev/mixer, etc as they would fight
El 16/09/15 a les 05:47, Bruno Félix Rezende Ribeiro ha escrit:
That said I think Rump opens up a lot of interesting possibilities.
I'm glad to see interest in that. Which particular area do you have
in mind?
I'm interested in USB support. I'd like to aim mass storage devices at
first.
For U
Hello Robert!
Em Tue, 15 Sep 2015 22:11:15 +0200
Robert Millan escreveu:
> I think it's mostly Zheng Da's merit.
Thank you Zheng Da! :-)
> That said I think Rump opens up a lot of interesting possibilities.
> I'm glad to see interest in that. Which particular area do you have
> in mind?
I'm
Hi Bruno,
El 14/09/15 a les 00:32, Bruno Félix Rezende Ribeiro ha escrit:
I'm interested in improving Hurd's hardware support, probably working
on the development of user-space device drivers[0], most likely the
rump kernel integration. I see that Robert Millan has made some
remarkable progres
Hello, GNU Hurd hackers!
I'm available to work on free software things of my choice full time
for at least the next six months. Besides helping the GNU project and
the FSF with some infrastructural work and campaigns, I've decided to
use all my remaining time to hack on the GNU Hurd. I'm a begin
26 matches
Mail list logo
