to the first instance of the char argument, but
does it also change where its first argument points?
*Andrew Eggenberger*
Thanks Samuel. So if I'm understanding correctly, if I let the RPC
vm_allocate() filebuf I don't need to worry about vm_deallocating it? And
if I wanted to pass a buffer in and reuse it, I should use vm_allocate()
instead of malloc()?
*Andrew Eggenberger*
read a POSIX manual.
I see your point. But this is more about the hurd-specific nature of
dir_readdir than the dirent struct. readdir in glibc returns one dirent at
a time, not something called an array that can’t be reliably treated as
one. That’s what this patch is meant to document.
Andrew
>
I wrote this patch for the website after struggling with dir_readdir.
Hopefully this will help the next person who needs it (probably me in a few
months).
*Andrew Eggenberger*
---
hurd/interface/fs/19.mdwn | 26 ++
1 file changed, 26 insertions(+)
diff --git a/hurd
e error, but it still
occurred.
The program works fine without mallocing the buffer at all, and it works
fine when
I malloc but don't free. But both of those would seem to create memory
leaks. Can
anyone help me understand what's going on here?
Thanks
*Andrew Eggenberger*
That worked. Thank you.
*Andrew Eggenberger*
On Mon, Apr 19, 2021 at 6:18 PM Samuel Thibault
wrote:
> Andrew Eggenberger, le dim. 18 avril 2021 20:27:09 -0500, a ecrit:
> > while(i++ < amt){
> > d = *(struct direct*)dirents;
>
> That cannot work: d_name is a f
> Did you build both your test program and your translator with
> -D_FILE_OFFSET_BITS=64? The RPC fills a dirent64 structure, not dirent
> only.
Yes. Do I need to cast it explicitly to a dirent64 or does the declaration
suffice?
--
*Andrew Eggenberger*
>
> Please send us the actual source code so we can check the details. It's
> the details that matter, not the high-level description
>
>
The procedure below demonstrates the behavior.
int
orgifydir (char** buf, mach_port_t root)
{
error_t err;
data_t dirents;
struct direct d;
//d/dirent.html
*Andrew Eggenberger*
I was just looking at sbcl. The SBCL source has platform and os-specific
makefiles. At the moment the OSes don’t include the Hurd. You can find them
in /src/runtime after running `apt-get source sbcl`. There are references
to it in the wiki so I think it was working at one time.
--
*Andrew
Hello,
The included patch adds a link to download the pdf of a file referenced
on the microkernel/mach/mig/documentation.mdwn page. Currently
there is only a link to the citation, and even that is paywalled.
*Andrew Eggenberger*
>From fde2e2d75382e67ec09e399c7ef7502da49535c7 Mon Sep 17 00
No worries! Thank you.
On Wed, Nov 11, 2020 at 3:26 AM Samuel Thibault
wrote:
> Samuel Thibault, le mer. 11 nov. 2020 10:18:49 +0100, a ecrit:
> > Andrew Eggenberger, le mar. 10 nov. 2020 21:24:27 -0600, a ecrit:
> > > I made a patch based on your advice that solves the
/* A connection queue we're attempting to connect through; a socket may
only be attempting one connection at a time. */
struct connq *connect_queue;
+
+ uid_t uid;
+
+ gid_t gid;
};
/* Socket flags */
*Andrew Eggenberger*
On Mon, Nov 9, 2020 at 2:53 PM Samuel Thibault
wrote:
>
> I think the problem is with the pflocal/io.c implementation of S_io_stat.
> emacsclient is trying to
> compare the uid provided by geteuid with the uid in the stat buffer from
> calling fstat on the
> file descriptor of a socket created with cloexec_socket (AF_UNIX,
> SOCK_STREAM, 0);. But
>
because of that, it's defaulting to 0 (as determined by memset). The
solution could be as
simple as adding
st->st_uid = geteuid(); // or something like that
to S_io_stat. But I'm still trying to figure out how to build and test it.
Andrew
*Andrew Eggenberger*
--
*Andrew Eggenberger*
I didn't even know that the latest version of Emacs compiled on the Hurd...
It does! The usual build instructions work fine as long as you have the
dependencies. For gccemacs
I recommend the "build from source" instructions at
https://www.emacswiki.org/emacs/GccEmacs#toc2
>
> I wish I could be
I recently built gccemacs 28 and found that when I tried to connect to
the server with emacsclient I would encounter the following error:
/home/demo/.local/bin/emacsclient: Invalid socket owner
/home/demo/.local/bin/emacsclient: No socket or alternate editor.
Please use:
--socket-name
osely and may have some patches
based on what I’ve found to be helpful to my own Hurd use.
Andrew
--
*Andrew Eggenberger*
isn't as user-friendly as it could be (chat transcripts, for
example). I think a lot could be cleaned up and made more usable short of a
complete redesign, not that one couldn't help.
*Andrew Eggenberger*
On Sun, Aug 16, 2020 at 9:42 AM Samuel Thibault
wrote:
> Samuel Thibault, le dim. 16 a
Hi,
Another patch attached. Hopefully this one addresses all the problems.
Thanks again.
--
Andrew Eggenberger
>From 533413ba62d8be167b09f508f23d7130f25688f2 Mon Sep 17 00:00:00 2001
From: Andrew Eggenberger
Date: Tue, 29 Oct 2019 23:19:32 -0500
Subject: [PATCH] add getrandom and getentr
rom 9357903b7d22ea1b54fb3c786e82b8fd0d08d996 Mon Sep 17 00:00:00 2001
From: Andrew Eggenberger
Date: Tue, 29 Oct 2019 23:19:32 -0500
Subject: [PATCH] add getrandom and getentropy implementations
squash! add getrandom and getentropy implementations
---
sysdeps/mach/hurd/getentropy.c |
Updated patch attached.
Thank you.
Andrew
>From a4e3233c9c21189267a9fb80588ff08f28f31729 Mon Sep 17 00:00:00 2001
From: Andrew Eggenberger
Date: Tue, 29 Oct 2019 23:19:32 -0500
Subject: [PATCH] add getrandom and getentropy implementations
---
sysdeps/mach/hurd/getentropy.c |
rit:
>> The issue here is actually that the source code is missing
>>
>> #define _FILE_OFFSET_BITS 64
>>
>> at the very top of the file.
>
> Or you can make the hooks use loff_t instead of off_t.
>
> Samuel
--
Andrew Eggenberger
Thank you. Yes, I misunderstood. All three methods work (independently) now.
Samuel Thibault writes:
> Hello,
>
> Andrew Eggenberger, le dim. 28 juil. 2019 04:21:21 -0500, a ecrit:
>> It's working now,
>
> Good :)
>
>> Both putting #define _FILE_OFFSET_BITS 64 an
24 matches
Mail list logo
