Re: [PATCH 5/6] GNU/Hurd: disable symbolize.

On 2025-02-07 23:51, Samuel Thibault wrote: Yuqian Yang, le ven. 07 févr. 2025 23:27:01 +0800, a ecrit: I know this is due to the way of our kernel to handle file and memory. Do we have a good way to fix this, Not a trivial way. It'd need adding names to the kernel map entries, and setting t

Re: [PATCH 5/6] GNU/Hurd: disable symbolize.

On Fri, Feb 7, 2025 at 6:51 PM Samuel Thibault wrote: > Yuqian Yang, le ven. 07 févr. 2025 23:27:01 +0800, a ecrit: > > I know this is due to the way of our kernel to handle file and memory. > > Do we have a good way to fix this, > > Not a trivial way. It'd need addi

Re: [PATCH 5/6] GNU/Hurd: disable symbolize.

Yuqian Yang, le ven. 07 févr. 2025 23:27:01 +0800, a ecrit: > I know this is due to the way of our kernel to handle file and memory. > Do we have a good way to fix this, Not a trivial way. It'd need adding names to the kernel map entries, and setting them from mmap() and such functions that map fi

Re: [PATCH 5/6] GNU/Hurd: disable symbolize.

When I fixed abseil[1] for Hurd, I disabled its debugging feature of finding the symbol of current functions or any other symbols.[2] It does not work on Hurd and its unit tests failed. It can be safely disabled and does not affect other functions of lib just like platforms that do not support it,

Re: [PATCH 6/6 gnumach] i386/apic: Fix condition on non-BSP

On Tue, Dec 10, 2024 at 12:40 AM Samuel Thibault wrote: > Applied, thanks! FWIW, I noticed that the last few commits from Damien have "Damien Zammit via Bug reports for the GNU Hurd " listed as the Git commit author. Sergey

Re: [PATCH 6/6 gnumach] i386/apic: Fix condition on non-BSP

Applied, thanks! Damien Zammit via Bug reports for the GNU Hurd, le lun. 09 déc. 2024 12:18:02 +, a ecrit: > The condition was intended for non-BSP processors to > disable timer, but apic_id != 0 means it could affect BSP > if its apic id is non-zero. Fixes this bug. > > --- > i386/i386/ap

Re: [PATCH 5/6 gnumach] smp: Use logical destination not physical apic id

p to 8 groups of processors. > > INIT and STARTUP is not changed here. > > --- > i386/i386/apic.c | 11 --- > i386/i386/apic.h | 4 > i386/i386/ast_check.c | 2 +- > i386/i386/mp_desc.c | 2 +- > i386/i386/smp.c | 14 +++--- >

Re: [PATCH 4/6 gnumach] pmap: Separate temporary_mapping from set_page_dir

Applied, thanks! Damien Zammit via Bug reports for the GNU Hurd, le lun. 09 déc. 2024 12:17:45 +, a ecrit: > Prepare for smp parallel init where we want to call these > two functions on different cpus at different times. > > --- > i386/i386/mp_desc.c | 1 + > i386/i386at/model_dep.c | 1

Re: [PATCH 3/6 gnumach] i386/cpuboot: Write gs selector correctly

Damien Zammit via Bug reports for the GNU Hurd, le lun. 09 déc. 2024 12:17:37 +, a ecrit: > To make selectors work reliably, we need to > write zero to it before writing its final value. $PERCPU_DS is different from $KERNEL_DS, so we don't need to switch through 0. > --- > i386/i386/cpuboot

Re: [PATCH 2/6 gnumach] i386/cpuboot: Dont use CPU_NUMBER_NO_STACK() early

Applied, thanks! Damien Zammit via Bug reports for the GNU Hurd, le lun. 09 déc. 2024 12:17:30 +, a ecrit: > Since we just set up the gs segment, we can use > CPU_NUMBER instead of CPU_NUMBER_NO_STACK. > --- > i386/i386/cpuboot.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > d

Re: [PATCH 1/6 gnumach] i386/cpuboot: Simplify for legibility

Damien Zammit via Bug reports for the GNU Hurd, le lun. 09 déc. 2024 12:17:23 +, a ecrit: > The current segmentation already adds -KERNELBASE. > But only when accessing the memory. I have applied this part, thanks! > Don't forget to reload gdt. > > --- > i386/i386/cpuboot.S | 10 --

[PATCH 6/6 gnumach] i386/apic: Fix condition on non-BSP

The condition was intended for non-BSP processors to disable timer, but apic_id != 0 means it could affect BSP if its apic id is non-zero. Fixes this bug. --- i386/i386/apic.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/i386/i386/apic.c b/i386/i386/apic.c index 41b335

[PATCH 5/6 gnumach] smp: Use logical destination not physical apic id

386/ast_check.c | 2 +- i386/i386/mp_desc.c | 2 +- i386/i386/smp.c | 14 +++--- i386/i386/smp.h | 4 ++-- 6 files changed, 23 insertions(+), 14 deletions(-) diff --git a/i386/i386/apic.c b/i386/i386/apic.c index 0b5be50f..41b33599 100644 --- a/i386/i386/apic.c +++ b/i386/i386/api

[PATCH 2/6 gnumach] i386/cpuboot: Dont use CPU_NUMBER_NO_STACK() early

Since we just set up the gs segment, we can use CPU_NUMBER instead of CPU_NUMBER_NO_STACK. --- i386/i386/cpuboot.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i386/i386/cpuboot.S b/i386/i386/cpuboot.S index 9ac86845..09855864 100644 --- a/i386/i386/cpuboot.S +++ b/i386/i386

[PATCH 4/6 gnumach] pmap: Separate temporary_mapping from set_page_dir

Prepare for smp parallel init where we want to call these two functions on different cpus at different times. --- i386/i386/mp_desc.c | 1 + i386/i386at/model_dep.c | 1 + i386/intel/pmap.c | 2 -- 3 files changed, 2 insertions(+), 2 deletions(-) diff --git a/i386/i386/mp_desc.c b/i386

[PATCH 0/6 gnumach] Preparation for parallel SMP init

Hi, This patchset consists of 6 patches that have been tested **not** to break both smp and non-smp systems, but get us closer to having smp working fully. The rationale for going with parallel init for smp is that APICs are not individually addressible for more than 8 cpus (in logical mode

[PATCH 3/6 gnumach] i386/cpuboot: Write gs selector correctly

To make selectors work reliably, we need to write zero to it before writing its final value. --- i386/i386/cpuboot.S | 2 ++ 1 file changed, 2 insertions(+) diff --git a/i386/i386/cpuboot.S b/i386/i386/cpuboot.S index 09855864..f549a2bc 100644 --- a/i386/i386/cpuboot.S +++ b/i386/i386/cpuboot.S @

[PATCH 1/6 gnumach] i386/cpuboot: Simplify for legibility

The current segmentation already adds -KERNELBASE. But only when accessing the memory. Don't forget to reload gdt. --- i386/i386/cpuboot.S | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/i386/i386/cpuboot.S b/i386/i386/cpuboot.S index 7e6c4770..9ac86845 100644 --- a

Re: [PATCH hurd 1/6] Restructure argument setup in hashbang

Applied, thanks! Flavio Cruz, le dim. 21 janv. 2024 16:07:52 -0500, a ecrit: > We do a few things here: > - Move search_path to the scope where it is used to make dependencies > more clear. > - Have a separate variable to store the file name we eventually need to > free and move the free logic

Re: [PATCH hurd 6/6] hurdio: use correct function signature for hurdio_mdmstate

Applied, thanks! Flavio Cruz, le dim. 21 janv. 2024 16:07:57 -0500, a ecrit: > --- > term/hurdio.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/term/hurdio.c b/term/hurdio.c > index c6e14a4..a3e2a0a 100644 > --- a/term/hurdio.c > +++ b/term/hurdio.c > @@ -613,8 +6

Re: [PATCH hurd 5/6] ftpfs: use correct function signature for interrupt_check

Applied, thanks! Flavio Cruz, le dim. 21 janv. 2024 16:07:56 -0500, a ecrit: > --- > ftpfs/ftpfs.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/ftpfs/ftpfs.c b/ftpfs/ftpfs.c > index 794439b..9310a56 100644 > --- a/ftpfs/ftpfs.c > +++ b/

Re: [PATCH hurd 4/6] x86_64: do not define mach_cpu_subtypes since we don't use it

Applied, thanks! Flavio Cruz, le dim. 21 janv. 2024 16:07:55 -0500, a ecrit: > --- > proc/cpu-types.c | 2 ++ > proc/host.c | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/proc/cpu-types.c b/proc/cpu-types.c > index 3d89d5a..7a814f6 100644 > --- a/proc/cpu-types.c > +++ b/proc/c

Re: [PATCH hurd 3/6] Fix warnings in fstests

Applied, thanks! Flavio Cruz, le dim. 21 janv. 2024 16:07:54 -0500, a ecrit: > --- > fstests/fstests.c | 1 - > fstests/timertest.c | 10 -- > 2 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/fstests/fstests.c b/fstests/fstests.c > index b776503..ca60203 100644 > ---

Re: [PATCH hurd 2/6] procfs: remove unused rootdir_symlink_make_node

Applied, thanks! Flavio Cruz, le dim. 21 janv. 2024 16:07:53 -0500, a ecrit: > Not needed since b2c97e251bb470e6f967c716081675a96dbde59c > --- > procfs/rootdir.c | 8 > 1 file changed, 8 deletions(-) > > diff --git a/procfs/rootdir.c b/procfs/rootdir.c > index 7742edd..206a541 100644 >

Re: [PATCH 1/6] replaced references to alioth with salsa.

Applied the series, thanks! jbra...@dismail.de, le sam. 25 mai 2024 23:39:55 -0400, a ecrit: > --- > faq/reporting_bugs.mdwn | 9 ++--- > hurd/running/debian/patch_submission.mdwn | 6 +++--- > 2 files changed, 9 insertions(+), 6 deletions(-) > >

[PATCH 3/6] removed emacs from the problematic packages page.

* open_issues/problematic_packages.mdwn: remove emacs --- open_issues/problematic_packages.mdwn | 5 - 1 file changed, 5 deletions(-) diff --git a/open_issues/problematic_packages.mdwn b/open_issues/problematic_packages.mdwn index 8fe06495..22054e6e 100644 --- a/open_issues/problematic_packa

[PATCH 6/6] I added in links to the subhurds page

Using the website just now, I had to search the internet to find the subhurd page. Perhaps these link will help others find the right page. * documenation.mdwn: add a link to subhurds * hurd.mdwn: add a link to subhurds * hurd/documentation: add a link to subhurds --- documentation.mdwn | 1

[PATCH 5/6] I added links to the existing translators page.

link to hurd/translator --- documentation.mdwn | 2 ++ hurd.mdwn | 2 ++ hurd/documentation.mdwn | 3 ++- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/documentation.mdwn b/documentation.mdwn index ebbde844..7d6556f4 100644 --- a/documentation.mdwn +++ b

[PATCH 4/6] I removed the 2 GiB file system limit on the ext2fs page.

* hurd/translator/ext2fs.mdwn: I inlined the faq entry that explains the ext2fs filesystem limitations. --- hurd/translator/ext2fs.mdwn | 21 ++--- 1 file changed, 14 insertions(+), 7 deletions(-) diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index 81e54df

[PATCH 2/6] On the emacs page, I mentioned that eglot is working.

* open_issues/emacs.mdwn: mentioned eglot working with c-mode --- open_issues/emacs.mdwn | 4 1 file changed, 4 insertions(+) diff --git a/open_issues/emacs.mdwn b/open_issues/emacs.mdwn index 21661f02..15a7c761 100644 --- a/open_issues/emacs.mdwn +++ b/open_issues/emacs.mdwn @@ -32,6 +32,10

[PATCH 1/6] replaced references to alioth with salsa.

--- faq/reporting_bugs.mdwn | 9 ++--- hurd/running/debian/patch_submission.mdwn | 6 +++--- 2 files changed, 9 insertions(+), 6 deletions(-) diff --git a/faq/reporting_bugs.mdwn b/faq/reporting_bugs.mdwn index 25be02ef..0e556cc1 100644 --- a/faq/reporting_bugs.mdwn +++ b

[PATCH 6/9] aarch64: Add exception type definitions

EXC_AARCH64_OFF4 /* floating-point overflow */ +#define EXC_AARCH64_DZF5 /* floating-point divide by zero */ +#define EXC_AARCH64_IOF6 /* floating-point invalid operation */ + +/* + * EXC_SOFTWARE

Re: [PATCH 3/6 gnumach] smp: Remove hardcoded AP_BOOT_ADDR

Applied and fixed, thanks! Damien Zammit, le lun. 05 févr. 2024 11:33:49 +, a ecrit: > This took some time to figure out. > Involves a hand-crafted 16 bit assembly instruction [1] > because it requires an immediate for the memory address > of far jump. This required self-modifying code > to i

Re: [PATCH 6/6 gnumach] smp: Fix INIT/STARTUP IPI sequence

Hello, Damien Zammit, le lun. 05 févr. 2024 11:34:09 +, a ecrit: > Outstanding: Find a way to allocate memory below 1MiB. We could make the biosmem's biosmem_bootstrap_common code reserve the first physical page it finds from the multiboot mem map. > diff --git a/i386/i386/mp_desc.c b/i386/i

Re: [PATCH 5/6 gnumach] smp: Use HPET instead of pit one-shot that is unreliable

ditto. Damien Zammit, le lun. 05 févr. 2024 11:34:03 +, a ecrit: > NB: Every x86 board that uses ACPI most likely has a HPET. > We can roll back to PIT in the cases where its not present, > but the PIT one shot code is definitely currently broken. > --- > i386/i386/smp.c | 7 +++ > 1 file

Re: [PATCH 4/6 gnumach] Add HPET timer for small accurate delays

0x10 > +# define HPET_CFG_ENABLE (1 << 0) > +# define HPET_LEGACY_ROUTE (1 << 1) > +#define HPET_COUNTER 0xf0 > +#define HPET_T0_CFG 0x100 > +# define HPET_T0_32BIT_MODE (1 << 8) >

Re: [PATCH 2/6 gnumach] separate lapic_enable from lapic_setup

Hello, Damien Zammit, le lun. 05 févr. 2024 11:33:44 +, a ecrit: > @@ -312,12 +313,10 @@ start_other_cpus(void) > memcpy((void*)phystokv(AP_BOOT_ADDR), (void*) &apboot, > (uint32_t)&apbootend - (uint32_t)&apboot); > > -#ifndef APIC > - lapic_enable(); /* Enable lapic o

Re: [PATCH 1/6 gnumach] Fix apic_send_ipi function clobbering read only fields

Applied, thanks! Damien Zammit, le lun. 05 févr. 2024 11:33:39 +, a ecrit: > This was the root cause of failing to INIT. > We were clobbering remote_read_status. > And also, we need to reference the .r register > when writing the ICR regs otherwise I think > it writes all of the block. > --- >

[PATCH 5/6 gnumach] smp: Use HPET instead of pit one-shot that is unreliable

NB: Every x86 board that uses ACPI most likely has a HPET. We can roll back to PIT in the cases where its not present, but the PIT one shot code is definitely currently broken. --- i386/i386/smp.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/i386/i386/smp.c b/i386/i38

[PATCH 3/6 gnumach] smp: Remove hardcoded AP_BOOT_ADDR

This took some time to figure out. Involves a hand-crafted 16 bit assembly instruction [1] because it requires an immediate for the memory address of far jump. This required self-modifying code to inject the next instruction, therefore I added a near jump to clear the instruction cache queue in ca

[PATCH 2/6 gnumach] separate lapic_enable from lapic_setup

This allows us to init the lapic without necessarily turning on the IOAPIC interrupts. --- i386/i386/apic.c | 15 +-- i386/i386/apic.h | 2 ++ i386/i386/mp_desc.c | 6 +++--- i386/i386at/ioapic.c | 1 + 4 files changed, 19 insertions(+), 5 deletions(-) diff --git a/i386

[PATCH 6/6 gnumach] smp: Fix INIT/STARTUP IPI sequence

Outstanding: Find a way to allocate memory below 1MiB. Otherwise, this hardcodes 0x3000 as the starting eip. TESTED: works in qemu TESTED: works hardware with AMD cpu --- i386/i386/mp_desc.c | 15 -- i386/i386/smp.c | 114 +--- i386/i386/smp.h

[PATCH 4/6 gnumach] Add HPET timer for small accurate delays

<< 8) +# define HPET_T0_VAL_SET (1 << 6) +# define HPET_T0_TYPE_PERIODIC (1 << 3) +# define HPET_T0_INT_ENABLE(1 << 2) +#define HPET_T0_COMPARATOR 0x108 + +#define FSEC_PER_NSEC 100 +#define NSEC_PER_USEC

[PATCH 0/6 gnumach] SMP on AMD hardware

Hi all, This patchset fixes a number of things wrong with smp and most of all fixes the root cause of an AP startup problem (Patch 1), which may also be affecting IPIs in general. In qemu with smp, I get a new panic after all modules are loaded: ../kern/slab.c:966: kmem_cache_alloc_from_slab: \

[PATCH 1/6 gnumach] Fix apic_send_ipi function clobbering read only fields

This was the root cause of failing to INIT. We were clobbering remote_read_status. And also, we need to reference the .r register when writing the ICR regs otherwise I think it writes all of the block. --- i386/i386/apic.c | 8 ++-- i386/i386/apic.h | 2 +- 2 files changed, 7 insertions(+), 3

Re: [PATCH 6/6] added short documentation for some translators.

jbra...@dismail.de, le ven. 26 janv. 2024 20:45:20 +, a ecrit: > January 22, 2024 at 6:49 PM, "Samuel Thibault" > wrote: > > Thanks for your contributions! Here are a few comments for the last bit. > > I just wanted to verify that I did get this email, and it

Re: [PATCH 6/6] added short documentation for some translators.

January 22, 2024 at 6:49 PM, "Samuel Thibault" wrote: > > Hello, > > Thanks for your contributions! Here are a few comments for the last bit. > > Samuel If you are ok with an the Hurd manual being converted to org-mode, then we could use the org-mode m

Re: [PATCH 6/6] added short documentation for some translators.

January 22, 2024 at 6:49 PM, "Samuel Thibault" wrote: > > Hello, > > Thanks for your contributions! Here are a few comments for the last bit. > > Samuel I just wanted to verify that I did get this email, and it's awesome that I can now work on the Hurd

Re: [PATCH 6/6] added short documentation for some translators.

+You can @code{ungzip} files on the fly with @code{storeio} > +(@code{bunzip2} is available as well.): > + > +@example > +$ settrans -ca foo.txt /hurd/storeio -T gunzip foo.gz > +@end example I'd say call the gz file foo.txt.gz An other interesting example is accessing partitions of

Re: [PATCH 5/6] trivial hurd manual changes.

Applied, thanks! Joshua Branson, le jeu. 21 sept. 2023 12:48:21 -0400, a ecrit: > From: "jbra...@dismail.de" > > * doc/hurd.texi (Special Files): added a reference to the zero store. > * doc/hurd.texi (Translators): added a sentence about /dev/random. > * doc/hurd.texi (Invoking 'mount'): added

Re: [PATCH 4/6] add a FAT FS section to the hurd manual.

Applied, thanks! Joshua Branson, le jeu. 21 sept. 2023 12:48:20 -0400, a ecrit: > From: "jbra...@dismail.de" > > * doc/hurd.texi (FAT FS): new section. > --- > doc/hurd.texi | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/doc/hurd.texi b/doc/hurd.texi > index 21118bb3..eb9946

Re: [PATCH 3/6] describe the ISO-9960 filesystem in the hurd manual.

Applied, thanks! Joshua Branson, le jeu. 21 sept. 2023 12:48:19 -0400, a ecrit: > From: "jbra...@dismail.de" > > * doc/hurd.texi (ISO-9960): I added in a short explanation. > --- > doc/hurd.texi | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/doc/hurd.texi b/doc/hu

Re: [PATCH 2/6] add a short ext2fs description to the hurd manual.

Applied, thanks! Joshua Branson, le jeu. 21 sept. 2023 12:48:18 -0400, a ecrit: > From: "jbra...@dismail.de" > > * doc/hurd.texi (Linux Extended 2 FS): added a short description. > --- > doc/hurd.texi | 14 -- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/doc/

Re: [PATCH 1/6] describe fixing filesystem corruption in the hurd manual.

Applied, thanks! Joshua Branson, le jeu. 21 sept. 2023 12:48:17 -0400, a ecrit: > From: "jbra...@dismail.de" > > * doc/hurd.texi (Repairing Filesystems): described fixing filesystem > corruption. > * doc/hurd.texi (Shutdown): added the hurd specific halt-hurd command. > --- > doc/hurd.texi | 53

[PATCH hurd 5/6] ftpfs: use correct function signature for interrupt_check

--- ftpfs/ftpfs.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/ftpfs/ftpfs.c b/ftpfs/ftpfs.c index 794439b..9310a56 100644 --- a/ftpfs/ftpfs.c +++ b/ftpfs/ftpfs.c @@ -51,8 +51,13 @@ struct ftpfs *ftpfs; /* Parameters describing the server we're connecti

[PATCH hurd 6/6] hurdio: use correct function signature for hurdio_mdmstate

--- term/hurdio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/term/hurdio.c b/term/hurdio.c index c6e14a4..a3e2a0a 100644 --- a/term/hurdio.c +++ b/term/hurdio.c @@ -613,8 +613,8 @@ hurdio_mdmctl (int how, int bits) } -static int -hurdio_mdmstate (void) +static err

[PATCH hurd 2/6] procfs: remove unused rootdir_symlink_make_node

Not needed since b2c97e251bb470e6f967c716081675a96dbde59c --- procfs/rootdir.c | 8 1 file changed, 8 deletions(-) diff --git a/procfs/rootdir.c b/procfs/rootdir.c index 7742edd..206a541 100644 --- a/procfs/rootdir.c +++ b/procfs/rootdir.c @@ -706,14 +706,6 @@ rootdir_file_make_node (voi

[PATCH hurd 3/6] Fix warnings in fstests

--- fstests/fstests.c | 1 - fstests/timertest.c | 10 -- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/fstests/fstests.c b/fstests/fstests.c index b776503..ca60203 100644 --- a/fstests/fstests.c +++ b/fstests/fstests.c @@ -94,7 +94,6 @@ main (void) #endif printf

[PATCH hurd 4/6] x86_64: do not define mach_cpu_subtypes since we don't use it

--- proc/cpu-types.c | 2 ++ proc/host.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/proc/cpu-types.c b/proc/cpu-types.c index 3d89d5a..7a814f6 100644 --- a/proc/cpu-types.c +++ b/proc/cpu-types.c @@ -38,6 +38,7 @@ const char *const mach_cpu_types[] = #endif }; +#ifndef __x86

[PATCH hurd 1/6] Restructure argument setup in hashbang

We do a few things here: - Move search_path to the scope where it is used to make dependencies more clear. - Have a separate variable to store the file name we eventually need to free and move the free logic to happen in a single place. Both of this allows us to still free the name even if a f

Re: [PATCH 6/6] added short documentation for some translators.

Joshua Branson, le jeu. 21 sept. 2023 12:48:22 -0400, a ecrit: > +Alternatively one can @emph{name} a pipe with the command > +@command{mkfifo }, which will persist until you remove it with > +the command @command{rm }. This lets you use commands that > +interact with the pipe from many different

Re: [PATCH 5/6] trivial hurd manual changes.

Joshua Branson, le jeu. 21 sept. 2023 12:48:21 -0400, a ecrit: > @@ -2110,6 +2110,15 @@ Only display files that have translators. > @node Invoking mount > @subsection Invoking @code{mount} > > +One does not mount filesystem partitions on the Hurd. Instead one > +sets a translator, which transl

[PATCH 3/6] describe the ISO-9960 filesystem in the hurd manual.

From: "jbra...@dismail.de" * doc/hurd.texi (ISO-9960): I added in a short explanation. --- doc/hurd.texi | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/hurd.texi b/doc/hurd.texi index 25b55ae7..21118bb3 100644 --- a/doc/hurd.texi +++ b/doc/hurd.texi @@ -3698,7 +3698,

[PATCH 5/6] trivial hurd manual changes.

From: "jbra...@dismail.de" * doc/hurd.texi (Special Files): added a reference to the zero store. * doc/hurd.texi (Translators): added a sentence about /dev/random. * doc/hurd.texi (Invoking 'mount'): added a short explanation. * doc/hurd.texi (Trivfs Callbacks): added @code{FSTYPE_MISC}. --- doc

[PATCH 2/6] add a short ext2fs description to the hurd manual.

From: "jbra...@dismail.de" * doc/hurd.texi (Linux Extended 2 FS): added a short description. --- doc/hurd.texi | 14 -- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/doc/hurd.texi b/doc/hurd.texi index ccad3228..25b55ae7 100644 --- a/doc/hurd.texi +++ b/doc/hurd.texi

[PATCH 4/6] add a FAT FS section to the hurd manual.

From: "jbra...@dismail.de" * doc/hurd.texi (FAT FS): new section. --- doc/hurd.texi | 9 + 1 file changed, 9 insertions(+) diff --git a/doc/hurd.texi b/doc/hurd.texi index 21118bb3..eb994656 100644 --- a/doc/hurd.texi +++ b/doc/hurd.texi @@ -3627,6 +3627,7 @@ workstations, as well. * R

[PATCH 6/6] added short documentation for some translators.

available as well.): + +@example +$ settrans -ca foo.txt /hurd/storeio -T gunzip foo.gz +@end example + +@code{libdiskfs} uses storeio: + +@example +@verbatim +$ fsysopts / | awk '{ print $5 " " $6}' + --store-type=typed part:1:device:hd0 +@end verbatim +@end example @nod

[PATCH 1/6] describe fixing filesystem corruption in the hurd manual.

From: "jbra...@dismail.de" * doc/hurd.texi (Repairing Filesystems): described fixing filesystem corruption. * doc/hurd.texi (Shutdown): added the hurd specific halt-hurd command. --- doc/hurd.texi | 53 +-- 1 file changed, 51 insertions(+), 2 delet

[PATCH v2 1/6] describe fixing filesystem corruption in the hurd manual.

* doc/hurd.texi (Repairing Filesystems): described fixing filesystem corruption. * doc/hurd.texi (Shutdown): added the hurd specific halt-hurd command. --- doc/hurd.texi | 53 +-- 1 file changed, 51 insertions(+), 2 deletions(-) diff --git a/doc/hur

[PATCH 1/6] describe fixing filesystem corruption in the hurd manual.

I would have documented how to make /etc/fstab auto-fsck /home, but reading /etc/fstab, I think I already did that on my /etc/fstab, and I always have to manually fsck /home. Also there have been times, that I HAD to manually fsck /. So it's good to show users how to fsck their partitions. E

Re: [RFC PATCH 6/7] vm: Add vm_map_coalesce_entry

On Mon, Jun 26, 2023 at 2:27 PM Sergey Bugaev wrote: > + /* > +* Get rid of the entry without changing any wirings or the pmap, > + * and without altering map->size. > +*/ > + prev->vme_end = entry->vme_end; > + vm_map_entry_unlink(map, entry); >

[RFC PATCH 6/7] vm: Add vm_map_coalesce_entry

This function attempts to coalesce a VM map entry with its preceeding entry. It wraps vm_object_coalesce. --- vm/vm_map.c | 77 +++-- vm/vm_map.h | 2 ++ 2 files changed, 77 insertions(+), 2 deletions(-) diff --git a/vm/vm_map.c b/vm/vm_map.c index

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Sergey Bugaev, le dim. 07 mai 2023 10:53:14 +0300, a ecrit: > On Sun, May 7, 2023 at 2:35 AM Samuel Thibault > wrote: > > Sergey Bugaev, le mar. 02 mai 2023 17:10:17 +0300, a ecrit: > > > As for the best way to implement this... I have always thought gnumach > > > should have a bootscript directi

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

On Sun, May 7, 2023 at 2:35 AM Samuel Thibault wrote: > Sergey Bugaev, le mar. 02 mai 2023 17:10:17 +0300, a ecrit: > > As for the best way to implement this... I have always thought gnumach > > should have a bootscript directive to expose a multiboot module as a > > memobj. Then there would be a

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Sergey Bugaev, le mar. 02 mai 2023 17:10:17 +0300, a ecrit: > As for the best way to implement this... I have always thought gnumach > should have a bootscript directive to expose a multiboot module as a > memobj. Then there would be a task, /hurd/ramdisk, that would expose > it over the device (an

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Samuel Thibault, le sam. 06 mai 2023 17:20:03 +0200, a ecrit: > Samuel Thibault, le ven. 05 mai 2023 19:23:57 +0200, a ecrit: > > Samuel Thibault, le ven. 05 mai 2023 17:30:11 +0200, a ecrit: > > > Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit: > > > > On Fri, May 5, 2023 at 4:30 PM Sa

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Samuel Thibault, le ven. 05 mai 2023 19:23:57 +0200, a ecrit: > Samuel Thibault, le ven. 05 mai 2023 17:30:11 +0200, a ecrit: > > Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit: > > > On Fri, May 5, 2023 at 4:30 PM Samuel Thibault > > > wrote: > > > > FI, I'm having debian hurd-amd64

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Sergey Bugaev, le sam. 06 mai 2023 01:42:27 +0300, a ecrit: > On Wed, May 3, 2023 at 1:37 AM Samuel Thibault > wrote: > > > Ah, I don't mean the troubles due to cross-compiling specifically (I > > > don't think the Hurd libraries are any more problematic compared to > > > the usual cross-compilin

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

building for x86_64. Just to give you an idea, here's my current diffstat, compared to 717897ca40be3bb78130617c8e880137eff96d96 (current origin/master): Makeconf | 2 +- Makefile | 6 ++- auth/auth.c | 29 +++--- boo

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

On Fri, May 5, 2023 at 9:07 PM Luca wrote: > I'll try to build a ramdisk with these packages and see where we get > (not far I suppose, mainly because of the issues introduced by my last > fs/gs base patch... :( ). Quick update, I'm already running ramdisk (with glibc and Hurd built locally, not

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Il 05/05/23 19:23, Samuel Thibault ha scritto: Samuel Thibault, le ven. 05 mai 2023 17:30:11 +0200, a ecrit: Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit: On Fri, May 5, 2023 at 4:30 PM Samuel Thibault wrote: FI, I'm having debian hurd-amd64 packages cross-built, I'm getting e.g

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Samuel Thibault, le ven. 05 mai 2023 17:30:11 +0200, a ecrit: > Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit: > > On Fri, May 5, 2023 at 4:30 PM Samuel Thibault > > wrote: > > > FI, I'm having debian hurd-amd64 packages cross-built, I'm getting e.g. > > > dash built, I'll probably h

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Sergey Bugaev, le ven. 05 mai 2023 18:15:00 +0300, a ecrit: > Hello, > > On Fri, May 5, 2023 at 4:30 PM Samuel Thibault > wrote: > > FI, I'm having debian hurd-amd64 packages cross-built, I'm getting e.g. > > dash built, I'll probably have rumpkernel built too. Essentially, we > > should be able

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

On Tue, 2023-05-02 at 17:10 +0300, Sergey Bugaev wrote: > On Mon, May 1, 2023 at 8:43 PM Samuel Thibault > wrote: > > > > > > They will just *not* work with 64bit. The glue code is not ready at all, > > and I think it's really not useful to spend time on that when we have > > the rump drivers wh

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Hello, On Fri, May 5, 2023 at 4:30 PM Samuel Thibault wrote: > FI, I'm having debian hurd-amd64 packages cross-built, I'm getting e.g. > dash built, I'll probably have rumpkernel built too. Essentially, we > should be able to debootstrap a whole chroot. Awesome! Are these (binaries? debs?) avai

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Samuel Thibault, le mer. 03 mai 2023 00:37:31 +0200, a ecrit: > Sergey Bugaev, le mer. 03 mai 2023 01:31:53 +0300, a ecrit: > > On Wed, May 3, 2023 at 1:20 AM Samuel Thibault > > wrote: > > > Actually, even what depends on it. That's the whole thing the > > > rebootstrap script I mentioned is abo

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Hi: > Even just starting a video blogging channel showing off the Hurd would > go a long way towards getting others more interested. (Maybe this is > something Joshua would be interested in doing?) I was thinking I could > live-stream some of my own hacking, seeing how this format is popular, > an

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

May 2, 2023 3:59 PM, "Sergey Bugaev" wrote: > Even just starting a video blogging channel showing off the Hurd would > go a long way towards getting others more interested. (Maybe this is > something Joshua would be interested in doing?) I was thinking I could > live-stream some of my own hackin

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Sergey Bugaev, le mer. 03 mai 2023 01:31:53 +0300, a ecrit: > On Wed, May 3, 2023 at 1:20 AM Samuel Thibault > wrote: > > Actually, even what depends on it. That's the whole thing the > > rebootstrap script I mentioned is about, and it's making progress, it > > should be able to produce essential

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

On Wed, May 3, 2023 at 1:20 AM Samuel Thibault wrote: > Actually, even what depends on it. That's the whole thing the > rebootstrap script I mentioned is about, and it's making progress, it > should be able to produce essentially what is needed to run > debootstrap/crosshurd. Ah, I don't mean the

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Sergey Bugaev, le mer. 03 mai 2023 01:16:29 +0300, a ecrit: > I see [0] -- is that it? Cool! > > [0]: https://salsa.debian.org/glibc-team/glibc/-/commits/hurd-amd64 It's part of it yes. > How does this work -- how does the Debian tooling know what > 'hurd-amd64' means? Is the full list of Debian

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

On Tue, May 2, 2023 at 11:43 PM Samuel Thibault wrote: > > Sergey Bugaev, le mar. 02 mai 2023 22:58:24 +0300, a ecrit: > > redoing bootstrap sounds rather interesting and challenging. It's not > > the most interesting thing right now though, which is why I haven't > > started really doing it yet.

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Sergey Bugaev, le mar. 02 mai 2023 22:58:24 +0300, a ecrit: > redoing bootstrap sounds rather interesting and challenging. It's not > the most interesting thing right now though, which is why I haven't > started really doing it yet. On that side, I'm working on it for the Debian part. It's almost

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

On Tue, May 2, 2023 at 10:06 PM Samuel Thibault wrote: > > Sergey Bugaev, le mar. 02 mai 2023 21:59:40 +0300, a ecrit: > > I don't see how network/disk/USB are relevant > > What I mean is that we don't have much workforce. If we keep > reimplementing things that already work fine enough, we'll not

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Sergey Bugaev, le mar. 02 mai 2023 21:59:40 +0300, a ecrit: > I don't see how network/disk/USB are relevant What I mean is that we don't have much workforce. If we keep reimplementing things that already work fine enough, we'll not be making useful progress. Samuel

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

On Tue, May 2, 2023 at 8:56 PM Samuel Thibault wrote: > > Sergey Bugaev, le mar. 02 mai 2023 19:34:02 +0300, a ecrit: > > On Tue, May 2, 2023 at 7:08 PM Samuel Thibault > > wrote: > > > > > > Sergey Bugaev, le mar. 02 mai 2023 18:47:50 +0300, a ecrit: &g

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

Sergey Bugaev, le mar. 02 mai 2023 21:46:14 +0300, a ecrit: > On Tue, May 2, 2023 at 7:48 PM Samuel Thibault > wrote: > > This will be just the fourth time that this part of the Hurd gets > > reimplemented? > > > > I mean, I agree that some pieces can be added to the picture and things > > be imp

Re: [PATCH v3 4/6] hurd: Add expected abilist files for x86_64

On Tue, May 2, 2023 at 7:48 PM Samuel Thibault wrote: > You'll need to store the /dev directory etc. And possibly some temporary > conf files for some translators, etc. Really, an initrd doesn't seem too > horrible a thing. Better maintain few powerful tools than a series of > small tools that the

Re: [PATCH v3 0/6] The remaining x86_64-gnu patches

On Tue, 2 May 2023, Sergey Bugaev via Libc-alpha wrote: > It would also probably make sense to mention my other changes, of > which there have been many, in the NEWS (would a simple "many fixes > and improvements in the Hurd port" suffice?) That may well be an appropriate way to describe them (if

Re: [PATCH v3 0/6] The remaining x86_64-gnu patches

On Tue, 2 May 2023, Samuel Thibault via Libc-alpha wrote: > Joseph Myers, le mar. 02 mai 2023 14:03:16 +, a ecrit: > > On Sat, 29 Apr 2023, Sergey Bugaev via Libc-alpha wrote: > > > > > If these patches are pushed, it should be possible for anyone to build > > > x86_64-gnu glibc just out of G

  1   2   3   4   5   6   >