Re: USB Mass Storage with rump
El 19/09/15 a les 00:52, Olaf Buddenhagen ha escrit: 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 implements the ugenhc NetBSD API, which is already supported by libusb, so if you want to support all libusb-aware applications, I think you'd just need something like: (cups|sane|whatever) ---> libusb > /dev/rumpusb (in Hurd VFS) > your translator > librump > /dev/ugenhc 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? Yes and no. If you load *HCI support and USB mass storage into Rump, you can have /dev/XXX pop up in the Rump namespace and that will be your disk node. Then you can write a translator to link the host system into that disk (or whatever way this is handled, does ext2fs open device nodes directly?). Note, however, unless the same Rump instance also exports raw USB access as described above, it will be the only possible user of USB in the system! Since you most likely want to provide multiplexing, authorisation, etc, to any application who wants to access USB, I wouldn't recommend to lump USB mass storage and *HCI in the same Rump instance. 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 ;-)) -- Robert Millan
Re: Sound translator
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 seems an unnecessary complication... That depends on the sound API you want to provide to applications. Rump doesn't implement OSS, but rather "Sun audio", which seems to be an ancestor of OSS, with very similar design. So if you wanted Sun audio, then yes it's a 1:1 wrapper. Otherwise you have to convert. I find OSS more useful than Sun audio myself, so I hacked a modified version of libossaudio (a conversion library included with NetBSD). This required a few changes to: - Make libossaudio use Rump as backend, rather than /dev/audio from the host - Make it build with non-NetBSD version of . My changes were for the Linux version but when I checked on GNU/Hurd it just needed minor adjustments. - Use modified versions of to define Rump _IOC* macros without namespace collision with system-wide ioctls. See: https://github.com/robertmillan/rumposs -- Robert Millan
Re: Sound translator / PCI device handling
[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 any devices to your liking..." See the Linux version of rumpcomp_pci_map() in pci-userspace [1]. IIRC this is used by librumpdev_pci to enumerate available PCI devices. Or if not that function, certainly something in that file ;-) On Linux, this is ultimately determined by UIO module settings (admin tells Linux which devices are available to user-space code, see [2] for UIO setup instructions). When I implemented the GNU/Hurd backend, I observed there's no such thing as Linux' UIO restricting access to PCI devices, so I simply made it use libpciaccess for scanning and blindly accepting anything it finds (not the Linux backend doesn't use libpciaccess at all, it just uses UIO for equivalent functionality). So AFAIK there's no framework to manage which devices are available to Rump, but if one wanted to implement it pci-userspace/src-gnu/ seems the place to do it. [1] https://github.com/rumpkernel/pci-userspace [2] https://github.com/rumpkernel/wiki/wiki/Howto%3A-Accessing-PCI-devices-from-userspace -- Robert Millan
Re: USB Mass Storage with rump (was: Full-time developer available)
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
Re: USB Mass Storage with rump
Robert Millan, le Sat 19 Sep 2015 10:52:13 +0200, a écrit : > If you load *HCI support and USB mass storage into Rump, you can have > /dev/XXX pop up in the Rump namespace and that will be your disk node. > Then you can write a translator to link the host system into that disk > (or whatever way this is handled, does ext2fs open device nodes directly?). It'd probably be easy to make ext2fs open a device node, just like we made pfinet do it. > Since you most likely want to provide multiplexing, authorisation, etc, to > any application who wants to access USB, I wouldn't recommend to lump > USB mass storage and *HCI in the same Rump instance. > > 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 ;-)) Indeed. We can however start with an all-in solution before adding multiplexing. Samuel
Re: Sound translator / PCI device handling (was: Full-time developer available)
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 multiplex accesses to the config space, but otherwise working on > > a PCI device can be separate (and even made safe by using VT-d when > > available!) > > That would be the ideal (also for netdde BTW) -- but considering this > will be more complex both in terms of implementation and design > considerations, I'm somewhat ambivalent as to whether this should be > attempted for the first take... Agreed, but let's keep that in mind as a target while coding stuff. Samuel
[PATCH] hurd: align -p and -pg behavior on Linux
On Linux, -p and -pg do not make gcc link against libc_p.a, only
-profile does (as documented in r11246), and thus people expect -p
and -pg to work without libc_p.a installed (it is actually even not
available any more in Debian). We should thus rather make the Hurd port
do the same to avoid build failures.
Samuel
* gcc/config/gnu.h (LIB_SPEC) [-p|-pg]: Link with -lc instead of -lc_p.
* gcc/config/i386/gnu.h (STARTFILE_SPEC) [-p|-pg]: Use gcrt1.o
instead of gcrt0.o.
--- gcc/config/gnu.h.orig 2015-09-16 00:43:09.785570853 +0200
+++ gcc/config/gnu.h2015-09-16 00:43:12.513550418 +0200
@@ -25,7 +25,7 @@
/* Default C library spec. */
#undef LIB_SPEC
-#define LIB_SPEC "%{pthread:-lpthread} %{pg|p|profile:-lc_p;:-lc}"
+#define LIB_SPEC "%{pthread:-lpthread} %{profile:-lc_p;:-lc}"
#undef GNU_USER_TARGET_OS_CPP_BUILTINS
#define GNU_USER_TARGET_OS_CPP_BUILTINS() \
--- gcc/config/i386/gnu.h.orig 2015-09-17 21:41:13.0 +
+++ gcc/config/i386/gnu.h 2015-09-17 23:03:57.0 +
@@ -27,11 +27,11 @@
#undef STARTFILE_SPEC
#if defined HAVE_LD_PIE
#define STARTFILE_SPEC \
- "%{!shared:
%{pg|p|profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}} \
+ "%{!shared:
%{pg|p:gcrt1.o%s;profile:gcrt0.o%s;pie:Scrt1.o%s;static:crt0.o%s;:crt1.o%s}} \
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
#else
#define STARTFILE_SPEC \
- "%{!shared: %{pg|p|profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} \
+ "%{!shared: %{pg|p:gcrt1.o%s;profile:gcrt0.o%s;static:crt0.o%s;:crt1.o%s}} \
crti.o%s %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}"
#endif
Re: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.
Flávio Cruz, le Thu 17 Sep 2015 02:05:33 +, a écrit :
>CHANGE_NODE_FIELD (cred,
> ({
>if (!(err = fshelp_isowner (&np->dn_stat, cred->user)))
> {
> - if (atime.microseconds == -1)
> + if (atime.tv_nsec == UTIME_NOW)
> np->dn_set_atime = 1;
> + else if (atime.tv_nsec == UTIME_OMIT)
> + ; /* do nothing */
Please take care of the existing indentation, here the code is using
tabs, so please use tabs. Otherwise it looks very odd when using a
different tabset (here you apparently assumed it to be 2, but other
people may be using something else).
Samuel
Re: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.
Sorry I didn't think about it at first, but inside the fallback on
file_utimes:
Flávio Cruz, le Thu 17 Sep 2015 02:05:33 +, a écrit :
> + if (err == MIG_BAD_ID || err == EOPNOTSUPP)
> +{
> + time_value_t atim, mtim;
> +
> + if (tsp == NULL)
> +/* Setting the number of microseconds to `-1' tells the
> + underlying filesystems to use the current time. */
> +atim.microseconds = mtim.microseconds = -1;
> + else
> +{
> + TIMESPEC_TO_TIME_VALUE (&atim, &(tsp[0]));
> + TIMESPEC_TO_TIME_VALUE (&mtim, &(tsp[1]));
> +}
> +
> + err = HURD_DPORT_USE (fd, __file_utimes (port, atim, mtim));
We should additionally check for tv_nsec being UTIME_OMIT, and in that
case return EOPNOTSUPP. Otherwise we'd be telling old translators a
very odd date.
Samuel
Re: Sound translator / PCI device handling
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 than "go out and see whether you can find any devices to your liking..." There's a way to limit which drivers attach to which devices in the "if you find a suitable device, only attach if it's at this bus/dev/fun" sense. However, that's not the same as limiting the pci probe. Besides, there's currently no easy way for the user to configure the attachment limits (involves going into the tree, editing ioconf files all around, and recompiling things). 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. That way you have the configuration in one format in one place. See the Linux version of rumpcomp_pci_map() in pci-userspace [1]. IIRC this is used by librumpdev_pci to enumerate available PCI devices. Or if not that function, certainly something in that file ;-) I admittedly haven't done anything with PCI for a while, so I may have forgotten how PCI works, but IIRC probing is done by reading configuration space registers. pci_map() is called only when a driver attaches to a device and needs to map the device registers. On Linux, this is ultimately determined by UIO module settings (admin tells Linux which devices are available to user-space code, see [2] for UIO setup instructions). When I implemented the GNU/Hurd backend, I observed there's no such thing as Linux' UIO restricting access to PCI devices, so I simply made it use libpciaccess for scanning and blindly accepting anything it finds (not the Linux backend doesn't use libpciaccess at all, it just uses UIO for equivalent functionality). So AFAIK there's no framework to manage which devices are available to Rump, but if one wanted to implement it pci-userspace/src-gnu/ seems the place to do it. Config space access is implemented via hypercalls, so you could just redirect the requests to some central authority which decides if the server in question should be allowed to access the config space of bus/dev(/fun) or just see -1. I'm not quite sure how you'd translate the central authority configuration into something human-manageable or automated. But then again, I sell only drivers, so that's not my problem ;)
Re: USB Mass Storage with rump
El 19/09/15 a les 10:59, Samuel Thibault 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 ;-)) Indeed. We can however start with an all-in solution before adding multiplexing. If you want an all-in solution, a simple way to do this could be to run a single Rump instance inside a single translator which exposes all of /dev in Rump namespace somewhere under host /dev hierarchy (e.g. /dev/rump/*). Then it becomes very easy to select what you want, and no matter what you do it's always a single Rump instance. For example: - if you want your /dev/hd1 to be a Rump USB mass storage, a symlink will do. - if you want raw access to network cards, one could have a translator which opens /dev/rump/bpf (Berkeley Packet Filter) to capture and inject packets. - if you want OSS rather than Sun audio, maybe you'll want a translator which opens /dev/rump/audio and exports OSS in /dev/audio, /dev/dsp, etc. -- Robert Millan
Re: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.
Hi Samuel
On Sat, 19 Sep 2015 at 14:22 Samuel Thibault
wrote:
> Sorry I didn't think about it at first, but inside the fallback on
> file_utimes:
>
> Flávio Cruz, le Thu 17 Sep 2015 02:05:33 +, a écrit :
> > + if (err == MIG_BAD_ID || err == EOPNOTSUPP)
> > +{
> > + time_value_t atim, mtim;
> > +
> > + if (tsp == NULL)
> > +/* Setting the number of microseconds to `-1' tells the
> > + underlying filesystems to use the current time. */
> > +atim.microseconds = mtim.microseconds = -1;
> > + else
> > +{
> > + TIMESPEC_TO_TIME_VALUE (&atim, &(tsp[0]));
> > + TIMESPEC_TO_TIME_VALUE (&mtim, &(tsp[1]));
> > +}
> > +
> > + err = HURD_DPORT_USE (fd, __file_utimes (port, atim, mtim));
>
> We should additionally check for tv_nsec being UTIME_OMIT, and in that
> case return EOPNOTSUPP. Otherwise we'd be telling old translators a very
> odd date.
Gotcha. I'm also checking for UTIME_NOW and then setting the time_value_t
microseconds field to -1 so that old translators use the current time.
Flávio
>
> Samuel
>
diff --git a/sysdeps/mach/hurd/bits/stat.h b/sysdeps/mach/hurd/bits/stat.h
index f60a58a..c2d0cc2 100644
--- a/sysdeps/mach/hurd/bits/stat.h
+++ b/sysdeps/mach/hurd/bits/stat.h
@@ -246,6 +246,10 @@ struct stat64
# define SF_NOUNLINK 0x0010 /* file may not be removed or renamed */
# define SF_SNAPSHOT 0x0020 /* snapshot inode */
+/* Time flags for futimens. */
+#define UTIME_NOW -1 /* corresponds to the current time */
+#define UTIME_OMIT -2 /* target time is omitted */
+
__BEGIN_DECLS
/* Set file flags for FILE to FLAGS. */
diff --git a/sysdeps/mach/hurd/futimens.c b/sysdeps/mach/hurd/futimens.c
index 4f82f1e..3159cb0 100644
--- a/sysdeps/mach/hurd/futimens.c
+++ b/sysdeps/mach/hurd/futimens.c
@@ -27,24 +27,51 @@
int
__futimens (int fd, const struct timespec tsp[2])
{
- time_value_t atime, mtime;
+ struct timespec atime, mtime;
error_t err;
if (tsp == NULL)
{
- /* Setting the number of microseconds to `-1' tells the
+ /* Setting the number of nanoseconds to UTIME_NOW tells the
underlying filesystems to use the current time. */
- atime.microseconds = mtime.microseconds = -1;
+ atime.tv_sec = 0;
+ atime.tv_nsec = UTIME_NOW;
+ mtime.tv_sec = 0;
+ mtime.tv_nsec = UTIME_NOW;
}
else
{
- atime.seconds = tsp[0].tv_sec;
- atime.microseconds = tsp[0].tv_nsec / 1000;
- mtime.seconds = tsp[1].tv_sec;
- mtime.microseconds = tsp[1].tv_nsec / 1000;
+ atime = tsp[0];
+ mtime = tsp[1];
}
- err = HURD_DPORT_USE (fd, __file_utimes (port, atime, mtime));
+ err = HURD_DPORT_USE (fd, __file_utimens (port, atime, mtime));
+
+ if (err == MIG_BAD_ID || err == EOPNOTSUPP)
+{
+ time_value_t atim, mtim;
+
+ if (tsp == NULL)
+/* Setting the number of microseconds to `-1' tells the
+ underlying filesystems to use the current time. */
+atim.microseconds = mtim.microseconds = -1;
+ else if (tsp[0].tv_nsec == UTIME_OMIT || tsp[1].tv_nsec == UTIME_OMIT)
+return EOPNOTSUPP;
+ else
+{
+ if (tsp[0].tv_nsec == UTIME_NOW)
+atim.microseconds = -1;
+ else
+TIMESPEC_TO_TIME_VALUE (&atim, &(tsp[0]));
+ if (tsp[1].tv_nsec == UTIME_NOW)
+mtim.microseconds = -1;
+ else
+TIMESPEC_TO_TIME_VALUE (&mtim, &(tsp[1]));
+}
+
+ err = HURD_DPORT_USE (fd, __file_utimes (port, atim, mtim));
+ }
+
return err ? __hurd_dfail (fd, err) : 0;
}
weak_alias (__futimens, futimens)
diff --git a/sysdeps/mach/hurd/futimes.c b/sysdeps/mach/hurd/futimes.c
index c325d44..dc8ae61 100644
--- a/sysdeps/mach/hurd/futimes.c
+++ b/sysdeps/mach/hurd/futimes.c
@@ -27,24 +27,44 @@
int
__futimes (int fd, const struct timeval tvp[2])
{
- union tv
- {
-struct timeval tv;
-time_value_t tvt;
- };
- const union tv *u = (const union tv *) tvp;
- union tv nulltv[2];
+ struct timespec atime, mtime;
error_t err;
if (tvp == NULL)
{
- /* Setting the number of microseconds to `-1' tells the
+ /* Setting the number of nanoseconds to UTIME_NOW tells the
underlying filesystems to use the current time. */
- nulltv[0].tvt.microseconds = nulltv[1].tvt.microseconds = -1;
- u = nulltv;
+ atime.tv_sec = 0;
+ atime.tv_nsec = UTIME_NOW;
+ mtime.tv_sec = 0;
+ mtime.tv_nsec = UTIME_NOW;
+}
+ else
+{
+ TIMEVAL_TO_TIMESPEC (&tvp[0], &atime);
+ TIMEVAL_TO_TIMESPEC (&tvp[1], &mtime);
+}
+
+ err = HURD_DPORT_USE (fd, __file_utimens (port, atime, mtime));
+ if (err == EMIG_BAD_ID || err == EOPNOTSUPP)
+{
+ time_value_t atim, mtim;
+
+ if (tvp == NULL)
+/* Setting the number of microseconds to `-1' tells the
+ underlying filesystems to use the current time. */
+atim.microseconds = mt
