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]

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 (, &(tsp[0]));
> > +  TIMESPEC_TO_TIME_VALUE (, &(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 (, &(tsp[0]));
+  if (tsp[1].tv_nsec == UTIME_NOW)
+mtim.microseconds = -1;
+  else
+TIMESPEC_TO_TIME_VALUE (, &(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 ([0], );
+  TIMEVAL_TO_TIMESPEC ([1], );
+}
+
+  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 = 

Re: USB Mass Storage with rump (was: Full-time developer available)

[Samuel Thibault]

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]

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

[Robert Millan]

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

[Robert Millan]

[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

[Samuel Thibault]

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

[PATCH] hurd: align -p and -pg behavior on Linux

[Samuel Thibault]

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: Sound translator / PCI device handling (was: Full-time developer available)

[Samuel Thibault]

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

Re: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.

[Samuel Thibault]

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 (, &(tsp[0]));
> +  TIMESPEC_TO_TIME_VALUE (, &(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

[Antti Kantee]

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: [PATCH] Change file_utimes RPC to use a struct timespec and update the servers to use UTIME_NOW and UTIME_OMIT.

[Samuel Thibault]

Flávio Cruz, le Thu 17 Sep 2015 02:05:33 +, a écrit :
>CHANGE_NODE_FIELD (cred,
>  ({
>if (!(err = fshelp_isowner (>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: USB Mass Storage with rump

[Robert Millan]

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