);
memchr returns a pointer 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
fter
reading it into the buffer might be causing the 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;
mach_msg_typ
doc.neutrino_lib_ref//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
-85,6 +85,10 @@ struct sock
/* 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, 202
>
> 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
> S_
And 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 s
oking at the site more closely and may have some patches
based on what I’ve found to be helpful to my own Hurd use.
Andrew
--
*Andrew Eggenberger*
esentation 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 Th
Hi,
Sorry. It’s in the mail. Shouldn’t be long now.
Andrew
On Tue, Nov 26, 2019 at 4:21 PM Samuel Thibault
wrote:
> Hello,
>
> Did you manage to get the copyright assignment done? I do not see your
> name in the GNU assignment records.
>
> With cheers,
> Samuel
>
--
*Andrew Eggenberger*
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
rew
>From 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/gete
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 |
Here's a really quick implementation just to get some feedback. Do you have any
suggestions for testing it or changes?
Thanks
Andrew
>From c9a6c3dcc5c4c880f3543961c5f1ad31157b788d Mon Sep 17 00:00:00 2001
From: Andrew Eggenberger
Date: Tue, 29 Oct 2019 00:19:28 -0500
Subject: [PATC
py() as a mere call to getrandom().
>
> (A copyright assignment for glibc will be needed)
>
> Samuel
>
> --
*Andrew Eggenberger*
27 juil. 2019 11:09:56 +0200, a ecrit:
>> 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
27 matches
Mail list logo
