Re: Sound translator

[Robert Millan]

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's very simple really. For rumposs I made OSS->Sun translation transparent
by integrating libossaudio directly into the source tree (note it had to be
integrated anyway, because of the modifications I stated in my previous mail).

You can do the same in a translator:

- Get ossaudio.c from rumposs, which includes all the necessary adjustments
(also just pushed GNU/Hurd fixes few minutes ago).

- Link it into your translator executable.

- Instead of forwarding ioctls to rump_sys_ioctl(), forward them to _oss_ioctl()
which is provided by ossaudio.c.


I find OSS more useful than Sun audio myself, so I hacked a modified
version of libossaudio (a conversion library included with NetBSD).


How does that work in NetBSD?


They provide libossaudio and then modify every OSS application to use 
_oss_ioctl()
and link with -lossaudio.

--
Robert Millan

Re: USB Mass Storage with rump

[Robert Millan]

El 24/09/15 a les 00:05, Olaf Buddenhagen ha escrit:

Instead, you could run a Rump instance with USB mass storage only
which uses libusb as backend rather than its own *HCI driver (but that
requires some coding work as it's currently not implemented ;-))


Yeah, I guess that's the price to pay if we want a properly layered
driver stack based on an originally monolithic implementation :-) As
long as we don't need to jump through hoops to achieve that (and it gets
upstream support), I'd say it's worth the effort...


If someone implements a libusb backend for Rump, I think upstream will be
more than happy to accept it.

On my experience, Rump upstream is demanding in terms of code quality, but
very friendly and always open to discuss things.

--
Robert Millan

Re: Full-time developer available

[Justus Winter]

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

Re: USB Mass Storage with rump

[Samuel Thibault]

Olaf Buddenhagen, le Thu 24 Sep 2015 00:11:26 +0200, a écrit :
> On Sat, Sep 19, 2015 at 10:59:39AM +0200, Samuel Thibault wrote:
> 
> > It'd probably be easy to make ext2fs open a device node, just like we
> > made pfinet do it.
> 
> As I already mentioned on IRC, I don't think we should emulate Mach
> device nodes at all here. Rather, the USB mass storage server(s) would
> export UNIX device nodes, which ext2fs/libstore can already deal with
> AFAIK.

But the fs RPC interface is much more involved to implement than the
device RPC interface. Storeio already does the conversion nicely, why
not reusing it?

Samuel

Re: Sound translator / PCI device handling

[Antti Kantee]

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 sounds to
me like the PCI server we are envisioning would be perfectly in line
with this design. The PCI server would expose one UNIX device node for
each PCI device present; and the Hurd backend in libpciaccess would open
these nodes to access the config space bits of any particular device.

The device node(s) to use would probably be passed as command line
parameters to each Rump translator instance -- so it would only see the
devices explicitly specified. No need for any other configuration :-)


Yea, sure, passing the device visibility info that way works too from 
the perspective of the rump kernel, because it still wouldn't know about 
the visibility directly ;)


It still doesn't make configuration fundamentally easier (or harder), 
though.

Re: (Newbie question) Failed building hurd on Debian GNU Hurd

[Braione Pietro]

Hello Samuel.
Il giorno 15/set/2015, alle ore 17:28, Samuel Thibault 
> ha scritto:

Hello,

Braione Pietro, le Tue 15 Sep 2015 12:31:16 +, a écrit :
../libports/libports.so: undefined reference to 
`mach_port_set_protected_payload’
../libports/libports.so: undefined reference to 
`mach_port_clear_protected_payload’

These are new features which were added to GNU Mach after the 2013
release.  To get them you need at least a newer glibc in addition to the
newer gnumach.

Since I want to be able to build the head version, I downloaded the 2015 Debian 
distribution and rebuilt everything (except for mig, but I don’t think this is 
the issue). I strictly followed the instructions at 
http://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html and 
http://www.gnu.org/software/hurd/hurd/building.html, in their non-Debian 
variant, plus make install of gnumach. It still fails, but now while linking 
the proc server:

…
make -C proc all
…
mgt.o: In function `S_mach_notify_new_task’:
/root/hurd/build/proc/../../proc/mgt.c:1081: undefined reference to 
`mach_notify_new_task’
collect2: error: ld returned 1 exit status

Can I suppose that I need a newer glibc? If yes, which of the many branches 
should I check out?
Best,
Pietro

Re: Fwd: Re: lib/50276: [PATCH] Portability fixes for ossaudio.c

[Samuel Thibault]

Hello,

Robert Millan, le Thu 24 Sep 2015 20:09:27 +0200, a écrit :
> >Why isn't adding the missing defines to the Hurd soundcard.h possible?
> 
> Not just possible but also desirable IMHO.

It may still be impossible at the moment actually.  The
SNDCTL_DSP_MAPINBUF and SNDCTL_DSP_MAPOUTBUF ioctls are precisely
examples: they pass a struct which contains the address of a buffer.
This can not be expressed with the current handling of ioctls in
GNU/Hurd: the sound server can't read/write the client process memory.

Samuel

Re: Fwd: Re: lib/50276: [PATCH] Portability fixes for ossaudio.c

[Robert Millan]

Hi Antti,

Adding bug-hurd to CC since some of the issues may concern them.

El 24/09/15 a les 16:02, Antti Kantee ha escrit:

On 24/09/15 10:43, Robert Millan wrote:


FYI:

https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=50276


If Hurd soundcard.h is missing those defines, doesn't it mean that some 
ossaudio programs will fail to compile on Hurd?


Note that most of the defines are missing on Linux too (the only exception being
SNDCTL_DSP_MAPINBUF and SNDCTL_DSP_MAPOUTBUF).

Aside from SNDCTL_DSP_MAPINBUF/SNDCTL_DSP_MAPOUTBUF potentially being an issue
with Hurd version of , the problem is not with applications
but with compiling ossaudio.c itself.


Why isn't adding the missing defines to the Hurd soundcard.h possible?


Not just possible but also desirable IMHO.

My point however isn't about running libossaudio in a specific OS, but rather
that since libossaudio is now potentially usable on just about every system that
could run Rump, I think it makes sense to make libossaudio more portable in 
general.

However if you disagree about that goal, it's no big deal. Users of this stack
can keep using it and carry the patches if needed.


The ABI used by old binaries will not change if you add new definitions, so I'm 
not sure I understand your motivation for patching NetBSD sources here.


Please also note that sys/soundcard.h is a vendor supplied header. Although on
Hurd I expect the developers would agree to improve sys/soundcard.h, in some
cases it's next to impossible.

Consider for example that on Linux this header is provided by the kernel, and:
  - their attitude towards OSS (which they consider deprecated in favour of 
ALSA)
  - their attitude towards user-space device driving on their platform (our 
recent
discussion about MSI support in UIO comes to mind here).

--
Robert Millan

Re: (Newbie question) Failed building hurd on Debian GNU Hurd

[James Clarke]

That’s an issue with the current Hurd repo on Savannah. You need this patch 
http://darnassus.sceen.net/gitweb/teythoon/packaging/hurd.git/blob/HEAD:/debian/patches/proc-task-notify-0005-proc-fix-build.patch,
 from what I gather (at least it fixes it for me).

James

> On 24 Sep 2015, at 13:50, Braione Pietro  
> wrote:
> 
> Hello Samuel.
>> Il giorno 15/set/2015, alle ore 17:28, Samuel Thibault 
>>  ha scritto:
>> 
>> Hello,
>> 
>> Braione Pietro, le Tue 15 Sep 2015 12:31:16 +, a écrit :
>>> ../libports/libports.so: undefined reference to 
>>> `mach_port_set_protected_payload’
>>> ../libports/libports.so: undefined reference to 
>>> `mach_port_clear_protected_payload’
>> 
>> These are new features which were added to GNU Mach after the 2013
>> release.  To get them you need at least a newer glibc in addition to the
>> newer gnumach.  
> 
> Since I want to be able to build the head version, I downloaded the 2015 
> Debian distribution and rebuilt everything (except for mig, but I don’t think 
> this is the issue). I strictly followed the instructions at 
> http://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html and 
> http://www.gnu.org/software/hurd/hurd/building.html, in their non-Debian 
> variant, plus make install of gnumach. It still fails, but now while linking 
> the proc server:
> 
> …
> make -C proc all
> …
> mgt.o: In function `S_mach_notify_new_task’:
> /root/hurd/build/proc/../../proc/mgt.c:1081: undefined reference to 
> `mach_notify_new_task’
> collect2: error: ld returned 1 exit status
> 
> Can I suppose that I need a newer glibc? If yes, which of the many branches 
> should I check out?
> Best,
> Pietro