Re: [PATCH 2/5 v3] rumpdisk: Link with rumpvfs_nofifofs if present
Applied, thanks! Damien Zammit, le mar. 28 déc. 2021 16:51:14 +1100, a ecrit: > --- > config.make.in| 1 + > configure.ac | 29 ++--- > rumpdisk/Makefile | 10 ++ > 3 files changed, 37 insertions(+), 3 deletions(-) > > diff --git a/config.make.in b/config.make.in > index e4f856f2..7c113c37 100644 > --- a/config.make.in > +++ b/config.make.in > @@ -108,6 +108,7 @@ HAVE_LIBLWIP = @HAVE_LIBLWIP@ > > # Whether we found librump. > HAVE_LIBRUMP = @HAVE_LIBRUMP@ > +HAVE_LIBRUMP_VFSNOFIFO = @HAVE_LIBRUMP_VFSNOFIFO@ > > # How to compile and link against liblwip. > liblwip_CFLAGS = @liblwip_CFLAGS@ > diff --git a/configure.ac b/configure.ac > index 9f131e9a..0c994061 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -233,11 +233,34 @@ AS_IF([test "x$with_libz" != xno], [ > ]) > AC_SUBST([HAVE_LIBZ]) > > -AC_CHECK_HEADER([rump/rump.h], [ > - AC_CHECK_LIB(rump, rump_init, [HAVE_LIBRUMP=yes], [HAVE_LIBRUMP=no]) > - ], [HAVE_LIBRUMP=no]) > +# Save > +oldLIBS="$LIBS" > + > +LIBS="-lrump" > +AC_LINK_IFELSE( > + [AC_LANG_PROGRAM( > +[[#include > +#define _STANDALONE > +#include ]], > + [])], > + [HAVE_LIBRUMP=yes], > + [HAVE_LIBRUMP=no]) > AC_SUBST([HAVE_LIBRUMP]) > > +LIBS="-lrumpvfs_nofifofs_pic" > +AC_LINK_IFELSE( > + [AC_LANG_PROGRAM( > +[[#include > +#define _STANDALONE > +#include ]], > + [])], > + [HAVE_LIBRUMP_VFSNOFIFO=yes], > + [HAVE_LIBRUMP_VFSNOFIFO=no]) > +AC_SUBST([HAVE_LIBRUMP_VFSNOFIFO]) > + > +# Reset > +LIBS="$oldLIBS" > + > AC_ARG_ENABLE(boot-store-types, > [ --enable-boot-store-types=TYPES... > list of store types included in statically > diff --git a/rumpdisk/Makefile b/rumpdisk/Makefile > index cf7c9df0..51304594 100644 > --- a/rumpdisk/Makefile > +++ b/rumpdisk/Makefile > @@ -19,6 +19,16 @@ RUMPPATH=/usr/lib > RUMPLIBS=rump rumpuser rumpdev rumpdev_disk rumpdev_pci rumpvfs > rumpdev_ahcisata > RUMPEXTRA=rumpdev_scsipi > > +# If we have a configured tree, include the configuration so that we > +# can conditionally build translators. > +ifneq (,$(wildcard ../config.make)) > + include ../config.make > +endif > + > +ifeq ($(HAVE_LIBRUMP_VFSNOFIFO),yes) > +RUMPLIBS += rumpvfs_nofifofs > +endif > + > dir := rumpdisk > makemode := server > > -- > 2.33.1 > > -- Samuel As usual, this being a 1.3.x release, I haven't even compiled this kernel yet. So if it works, you should be doubly impressed. (Linus Torvalds, announcing kernel 1.3.3 on the linux-kernel mailing list.)
Re: [PATCH] hurd: Implement device memory mapping
Hi, El 19/12/21 a les 16:40, Samuel Thibault ha escrit: “ For objects where read data and write data are the same, these objects will be equal, otherwise they will be disjoint. ” In that case, which one should we return as pager? Probably the right thing is to return an error, since a caller asking for RW permissions is expecting to receive a pager with both permissions. Either robj & wobj are equal and not null, or return an error.
Re: [PATCH] hurd: Implement device memory mapping
Joan Lledó, le mar. 28 déc. 2021 13:26:12 +0100, a ecrit: > El 19/12/21 a les 16:40, Samuel Thibault ha escrit: > > “ > > For objects where read data and write data are the same, these objects > > will be equal, otherwise they will be disjoint. > > ” > > > > In that case, which one should we return as pager? Probably the right thing > is to return an error, since a caller asking for RW permissions is expecting > to receive a pager with both permissions. Either robj & wobj are equal and > not null, or return an error. ? The interface explicitly says they can be different. Samuel
Re: [PATCH] hurd: Implement device memory mapping
Hi,
El 28/12/21 a les 13:55, Samuel Thibault ha escrit:
? The interface explicitly says they can be different.
Samuel
Sorry, I was confused. I meant the function pci_device_hurd_map_range at
libpciaccess. If io_map returns different ports for robj and wobj, we
can only assign one of them to the variable pager, which we send to
vm_map. Since we can only pass one of them to vm_map, when io_map
returns different values for robj and wobj we could return an error and
don't map. Something like this:
case VM_PROT_READ|VM_PROT_WRITE:
if (robj == wobj) {
if (robj == MACH_PORT_NULL)
return EPERM;
pager = wobj;
/* Remove extra reference. */
mach_port_deallocate (mach_task_self (), pager);
}
else {
if (robj != MACH_PORT_NULL)
mach_port_deallocate (mach_task_self (), robj);
if (wobj != MACH_PORT_NULL)
mach_port_deallocate (mach_task_self (), wobj);
return EPERM;
}
break;
Re: [PATCH] hurd: Implement device memory mapping
Joan Lledó, le mar. 28 déc. 2021 17:48:20 +0100, a ecrit: > El 28/12/21 a les 13:55, Samuel Thibault ha escrit: > > > > ? The interface explicitly says they can be different. > > > > Sorry, I was confused. I meant the function pci_device_hurd_map_range at > libpciaccess. If io_map returns different ports for robj and wobj, we can > only assign one of them to the variable pager, which we send to vm_map. Ah, ok :) > Since we can only pass one of them to vm_map, when io_map returns different > values for robj and wobj we could return an error and don't map. Yes, that'll be simpler. Samuel
