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
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
17 matches
Mail list logo
