Re: [web: guix updates 4/4] Mention recent Guix recent developments and status.

been integrated in Guix. > --- > # Documentation > > -As Hurd support is integrated in Guix, the official documentation > (<https://guix.gnu.org/en/manual/devel/>) also works for Hurd. > +As Hurd support is integrated in Guix, the [official > +documentation](https://gu

[web: guix updates 4/4] Mention recent Guix recent developments and status.

al/devel/>) also works for Hurd. +As Hurd support is integrated in Guix, the [official +documentation](https://guix.gnu.org/manual/en/html_node/) also works +for Hurd. -Guix has even support in its configuration language for creating Hurd VMs from a running Guix system (<https://g

[Web pages:Faq updates and misc 3/5] I updated the 64 bit port status.

* faq/64-bit.mdwn: updated status information: libdiskfs/ext2fs deadlocks * open_issues/64-bit_port.mdwn: I mentioned the status of bootstrap efforts of Debian Hurd, Alpine-Hurd, and Guix Hurd. --- faq/64-bit.mdwn | 9 ++--- open_issues/64-bit_port.mdwn | 12 +++- 2

Re: [PATCH] open_issues/arm_port.mdwn: documented Sergeys AArch64 port status.

Applied, thanks! jbra...@dismail.de, le mar. 09 janv. 2024 15:20:47 -0500, a ecrit: > I figure that we might as well document the AArch64 port status on the wiki. > > --- > open_issues/arm_port.mdwn | 172 +- > 1 file changed, 134 insertions(+

[PATCH] open_issues/arm_port.mdwn: documented Sergeys AArch64 port status.

I figure that we might as well document the AArch64 port status on the wiki. --- open_issues/arm_port.mdwn | 172 +- 1 file changed, 134 insertions(+), 38 deletions(-) diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn index 26e0b770..8a2bc27f

Re: rumpdisk status

ult wrote: > > > Had you tested support for cd-rom? With qemu I am getting a media sense > > > error with status 0x50. > > > > I think that was the reason for the qemu patch for syncing IDE cache > iirc. > > I thought so too and tried so, with the same result. > > Samuel > >

Re: rumpdisk status

Damien Zammit, le mar. 24 nov. 2020 11:15:15 +1100, a ecrit: > On 24/11/20 5:16 am, Samuel Thibault wrote: > > Had you tested support for cd-rom? With qemu I am getting a media sense > > error with status 0x50. > > I think that was the reason for the qemu patch for synci

Re: rumpdisk status

On 24/11/20 5:16 am, Samuel Thibault wrote: > Hello, > > Had you tested support for cd-rom? With qemu I am getting a media sense > error with status 0x50. I think that was the reason for the qemu patch for syncing IDE cache iirc. Damien

Re: rumpdisk status

Hello, Had you tested support for cd-rom? With qemu I am getting a media sense error with status 0x50. Samuel

Re: rumpdisk status

= 0x0, prevp = 0x1003ef5c, notifies = 0x0, interrupted_next = 0x1fffd30} status = err = outp = 0x2001d40 RetCodeType = #6 0x0815fea0 in mach_msg_server_timeout () No symbol table info available. #7 0x0804db65 in ports_manage_port_operations_one_thread (bucket=0x1000

Re: rumpdisk status

Damien Zammit, le mar. 10 nov. 2020 21:11:31 +1100, a ecrit: > I also printed inside rumpdisk to dump the offsets before calling > pread/pwrite, > these offsets are sometimes wider than 32 bits, sometimes not. Ok. Do pread/pwrite get called concurrently, or is pread/pwrite always finished before

Re: rumpdisk status

Hi Samuel, On 10/11/20 6:21 pm, Samuel Thibault wrote: >> It seems to be compiled with -D_FILE_OFFSET_BITS=64 already by default: > > But is rumpkernel itself also built with it? > > Really, better actually *test* that offsets are getting properly > propagated. Test program output: ``` ... wd0:

Re: rumpdisk status

Damien Zammit, le mar. 10 nov. 2020 13:17:52 +1100, a ecrit: > On 10/11/20 10:39 am, Samuel Thibault wrote: > >> sdd2 is / that boots with rumpdisk.static > >> sdd3 is the second partition I am trying to mount with the injected > >> translator > > > > That's far... Unless rumpdisk is built with _

Re: rumpdisk status

Hi, On 10/11/20 10:39 am, Samuel Thibault wrote: >> sdd2 is / that boots with rumpdisk.static >> sdd3 is the second partition I am trying to mount with the injected >> translator > > That's far... Unless rumpdisk is built with _FILE_OFFSET_BITS 64, its > off_t etc. will be 32bit, thus probably i

Re: rumpdisk status

Damien Zammit, le mar. 10 nov. 2020 11:01:29 +1100, a ecrit: > On 10/11/20 6:06 am, Samuel Thibault wrote: > > Perhaps add prints in the rump code to determine what really returns > > that error and why. Possibly it's really a constraint of wd0d, perhaps > > it can only be opened once at a time. >

Re: rumpdisk status

Hi, On 10/11/20 6:06 am, Samuel Thibault wrote: > Perhaps add prints in the rump code to determine what really returns > that error and why. Possibly it's really a constraint of wd0d, perhaps > it can only be opened once at a time. I am getting EBUSY when trying to reopen /dev/wd0d in rump_sys_op

Re: rumpdisk status

Damien Zammit, le mar. 10 nov. 2020 10:33:39 +1100, a ecrit: > Hi, > > On 10/11/20 6:12 am, Samuel Thibault wrote: > > Btw, is your second partition within small bounds? (e.g. within 4GiB > > that can be expressed with 32bit integers) > > Device Boot Start End Sectors Size Id Typ

Re: rumpdisk status

Hi, On 10/11/20 6:12 am, Samuel Thibault wrote: > Btw, is your second partition within small bounds? (e.g. within 4GiB > that can be expressed with 32bit integers) Device Boot Start End Sectors Size Id Type /dev/sdd12048 1953791 1951744 953M 82 Linux swap / Solar

Re: rumpdisk status

Samuel Thibault, le lun. 09 nov. 2020 20:06:28 +0100, a ecrit: > I'd say track the offset within the pread calls, to make sure that it is > not getting lost along the path. Also, I'd say put prints around the pread and pwrite calls. Actually now realizing that rumpdisk is for now single-threaded,

Re: rumpdisk status

Damien Zammit, le lun. 09 nov. 2020 19:43:05 +1100, a ecrit: > On 9/11/20 4:50 am, Samuel Thibault wrote: > > But you can as well replace these two calls with a single tall to > > rump_sys_pread() that avoids such issue (ditto for write). > > http://git.zammit.org/hurd-sv.git/log/ > > Even with t

Re: rumpdisk status

Hi, On 9/11/20 4:50 am, Samuel Thibault wrote: > But you can as well replace these two calls with a single tall to > rump_sys_pread() that avoids such issue (ditto for write). http://git.zammit.org/hurd-sv.git/log/ Even with the new pread/pwrite calls, it still seems to mix up the reads/writes b

Re: rumpdisk status

Samuel Thibault, le dim. 08 nov. 2020 18:50:12 +0100, a ecrit: > But you can as well replace these two calls with a single tall to > rump_sys_pread() that avoids such issue (ditto for write). (IIRC we had already discussed about it and left it in some TODO-list, is that recorded somewhere?) Samue

Re: rumpdisk status

Damien Zammit, le dim. 08 nov. 2020 16:10:32 +1100, a ecrit: > I am using the libparted access method via > storeio `-T typed part:x` but using the same underlying device. > Do I need to make opening a new partition on the same disk device > open a new handle on the same disk? Since your device_r

Re: rumpdisk status

Hi Samuel, When I access a different partition on the same disk, I am using the libparted access method via storeio `-T typed part:x` but using the same underlying device. Do I need to make opening a new partition on the same disk device open a new handle on the same disk? If so, how? I think cu

Re: rumpdisk status

Damien Zammit, le dim. 08 nov. 2020 10:41:47 +1100, a ecrit: > On 8/11/20 2:35 am, Samuel Thibault wrote: > > Perhaps, before mounting, try to run > > DISK > > fdisk -l /dev/wd0 > > root@zamhurd:~# showtrans /dev/wd0 > /hurd/storeio -T typed device:@/dev/rumpdisk:/dev/wd0 > root@zamhurd:~# fdis

Re: rumpdisk status

Hi, On 8/11/20 2:35 am, Samuel Thibault wrote: > Perhaps, before mounting, try to run DISK > fdisk -l /dev/wd0 root@zamhurd:~# showtrans /dev/wd0 /hurd/storeio -T typed device:@/dev/rumpdisk:/dev/wd0 root@zamhurd:~# fdisk -l /dev/wd0 ext2fs: part:2:device:/dev/wd0: warning: FILESYSTEM NOT UNMO

Re: rumpdisk status

Hello, Damien Zammit, le sam. 07 nov. 2020 18:39:32 +1100, a ecrit: > I think I managed to get the rumpdisk bootstrapped translator installed on a > filesystem node, Yay :) > but when I try to mount a second partition on the same disk it crashes the / > partition. Perhaps, before mounting, t

rumpdisk status

Hi all, I think I managed to get the rumpdisk bootstrapped translator installed on a filesystem node, but when I try to mount a second partition on the same disk it crashes the / partition. ``` root@zamhurd:~# showtrans /dev/wd0s3 /hurd/storeio -T typed part:3:device:@/dev/rumpdisk:/dev/wd0 ?2

Re: PCI Arbiter status

El dc. 04 de 09 de 2019 a les 19:42 +1000, en/na Damien Zammit va escriure: > I have not sent patches to pciutils, but I do seem to have a git > branch > that I was working on - based on upstream. I'm happy to share > patches. > I think it was based on your existing work, Joan. Is it a public bra

Re: PCI Arbiter status

Damien Zammit, le mer. 04 sept. 2019 19:42:03 +1000, a ecrit: > On 4/9/19 6:10 am, Joan Lledó wrote: > > 3- In libpciaccess upstream there are some commits by Damien Zammit, > > one of them with the new modules for the Hurd. I wonder: this new > > module expects to be used from both user tasks and

Re: PCI Arbiter status

On 4/9/19 6:10 am, Joan Lledó wrote: > 3- In libpciaccess upstream there are some commits by Damien Zammit, > one of them with the new modules for the Hurd. I wonder: this new > module expects to be used from both user tasks and the translator? There are currently two modes of operation in libpci

Re: PCI Arbiter status

Joan Lledó, le mar. 03 sept. 2019 22:10:38 +0200, a ecrit: > netdde -> libpciaccess -> arbiter -> libpciaccess -> hardware > > Am I right? Yes. > But I don't see the code commited in hurd's upstream, is > it because nobody reviewed it, or is there some problem? It's because even if it's c

Re: PCI Arbiter status

Hi! On Tue, 2019-09-03 at 22:10:38 +0200, Joan Lledó wrote: > 4- About pciutils, is something ours in upstream? Damien, did you send > patches to pciutils? FWIW, I'm happy to carry Hurd-specific patches in pcutils in Debian as long as they have not yet been merged upstream. Thanks, Guillem

PCI Arbiter status

Hello Hurd, Now I've finished porting lwip 2.1.2, I'd like to work on the pci arbiter again. Before starting to work, I'd like to know the current status of the arbiter. I've been taking a look at the old mails, please tell me if I'm wrong: 1- If I understood it right,

Re: Wiki edits: http -> https, updated status page, fsysopts page, and translator primer

Hello, Joshua Branson, le mer. 31 oct. 2018 14:58:30 -0400, a ecrit: > The subject says it all. I have applied it except the URL changes Thanks! Samuel

Re: Wiki edits: http -> https, updated status page, fsysopts page, and translator primer

> > The articles are these: > > https://www.gnu.org/software/hurd/microkernel/mach/gnumach/building.html > In this article we have to change: > > $ git clone http://git.savannah.gnu.org/cgit/hurd/gnumach.git/ > > with this > > $ git clone https://git.savannah.gnu.org/git/hurd/gnumach.git > > https:

Wiki edits: http -> https, updated status page, fsysopts page, and translator primer

und support in the status page. I gave a simple fsysopts example to with the hello translator. I added an fsysopts example to the translator_primer webpage. --- hurd/documentation/translator_primer.mdwn | 13 + hurd/fsysopts.mdwn | 15 +++ h

Re: Heads up: Recent status: emacs24/25 FTBFS since a long time on GNU/Hurd

Hello, Svante Signell, on Sat 10 Dec 2016 20:52:20 +0100, wrote: > On Thu, 2016-12-08 at 16:32 +0100, Richard Braun wrote: > > On Thu, Dec 08, 2016 at 03:40:34PM +0100, Svante Signell wrote: > > > > > OK! Then maybe the sbrk() feature should be flagged as not > > > available in order > > > not to

Re: Heads up: Recent status: emacs24/25 FTBFS since a long time on GNU/Hurd

On Thu, 2016-12-08 at 16:32 +0100, Richard Braun wrote: > On Thu, Dec 08, 2016 at 03:40:34PM +0100, Svante Signell wrote: > > > OK! Then maybe the sbrk() feature should be flagged as not > > available in order > > not to fool configure and the compiler. In fact FreeBSD/arm64 did > > exactly that,

Re: Heads up: Recent status: emacs24/25 FTBFS since a long time on GNU/Hurd

On Thu, Dec 08, 2016 at 03:40:34PM +0100, Svante Signell wrote: > I've read it, thanks! I think emacs is in a similar situation as Hurd with > respect to the still missing mlockall/munlockall functions. Except we're not fighting to keep the status quo. We will adapt and

Re: Heads up: Recent status: emacs24/25 FTBFS since a long time on GNU/Hurd

On Thu, 2016-12-08 at 14:47 +0100, Richard Braun wrote: > On Thu, Dec 08, 2016 at 10:44:09AM +0100, Svante Signell wrote: > > Since a long time emacs FTBFS due to unknown reasons. The latest version > > building was Debian 24.5+1-5, from 28 Nov 2015. > > As already mentioned, the real issue is in

Re: Heads up: Recent status: emacs24/25 FTBFS since a long time on GNU/Hurd

On Thu, Dec 08, 2016 at 10:44:09AM +0100, Svante Signell wrote: > Since a long time emacs FTBFS due to unknown reasons. The latest version > building was Debian 24.5+1-5, from 28 Nov 2015. As already mentioned, the real issue is in Emacs. See the relevant LWN article [1] for details. > Even befor

Heads up: Recent status: emacs24/25 FTBFS since a long time on GNU/Hurd

Hello bug-hurd ML, Since a long time emacs FTBFS due to unknown reasons. The latest version building was Debian 24.5+1-5, from 28 Nov 2015. Even before successful builds were by pure luck. One suspicious issue is that emacs use sbrk() for memory allocation, right? Notably sbrk() is not fool-proof

Test status update for dbus, glib2.0 and gamin

Hi, in order not to leave all results on #hurd@irc I'm updating the current status: with my patched eglibc supporting SCM_CREDS this is the current test status: good news: all 10 gamin tests pass, 5(8) dbus, 51(52) glib2.0, 58(62) glib2.0/gio bad news: emacs in X still hangs, many X-w

Re: [PATCH] procfs: another fix for the process file name in stat/status

Pino Toscano, le Mon 10 Sep 2012 18:16:44 +0200, a écrit : > Updated patch attached. Applied, thanks! Samuel

Re: [PATCH] procfs: another fix for the process file name in stat/status

Pino Toscano, le Mon 10 Sep 2012 18:16:44 +0200, a écrit : > Alle lunedì 10 settembre 2012, Samuel Thibault ha scritto: > > Pino Toscano, le Mon 10 Sep 2012 17:31:32 +0200, a écrit : > > > Alle domenica 9 settembre 2012, Samuel Thibault ha scritto: > > > > Pino Toscano, le Fri 07 Sep 2012 20:02:56

Re: [PATCH] procfs: another fix for the process file name in stat/status

t. You can use strchrnul instead. Indeed -- I didn't know it, thanks for the hint. Updated patch attached. -- Pino Toscano From b376dd34c0da95ff2e63e8f91e076f306f88bbd5 Mon Sep 17 00:00:00 2001 From: Pino Toscano Date: Mon, 10 Sep 2012 18:14:48 +0200 Subject: [PATCH] PID stat/status:

Re: [PATCH] procfs: another fix for the process file name in stat/status

Pino Toscano, le Mon 10 Sep 2012 17:31:32 +0200, a écrit : > Alle domenica 9 settembre 2012, Samuel Thibault ha scritto: > > Pino Toscano, le Fri 07 Sep 2012 20:02:56 +0200, a écrit : > > > +static int args_filename_length (const char *name) > > > +{ > > > + const char *p = name; > > > + while (*

Re: [PATCH] procfs: another fix for the process file name in stat/status

Alle domenica 9 settembre 2012, Samuel Thibault ha scritto: > Pino Toscano, le Fri 07 Sep 2012 20:02:56 +0200, a écrit : > > +static int args_filename_length (const char *name) > > +{ > > + const char *p = name; > > + while (*p != '\0' && *p != ' ') > > +++p; > > Why not using index(name, '

Re: [PATCH] procfs: another fix for the process file name in stat/status

Guillem Jover, le Sun 09 Sep 2012 01:22:43 +0200, a écrit : > On Sun, 2012-09-09 at 00:22:11 +0200, Samuel Thibault wrote: > > Pino Toscano, le Fri 07 Sep 2012 20:02:56 +0200, a écrit : > > > +static int args_filename_length (const char *name) > > > +{ > > > + const char *p = name; > > > + while

Re: [PATCH] procfs: another fix for the process file name in stat/status

On Sun, 2012-09-09 at 00:22:11 +0200, Samuel Thibault wrote: > Pino Toscano, le Fri 07 Sep 2012 20:02:56 +0200, a écrit : > > +static int args_filename_length (const char *name) > > +{ > > + const char *p = name; > > + while (*p != '\0' && *p != ' ') > > +++p; > > Why not using index(name, '

Re: [PATCH] procfs: another fix for the process file name in stat/status

Pino Toscano, le Fri 07 Sep 2012 20:02:56 +0200, a écrit : > +static int args_filename_length (const char *name) > +{ > + const char *p = name; > + while (*p != '\0' && *p != ' ') > +++p; Why not using index(name, ' ') here? > + return p - name; > +} Samuel

[PATCH] procfs: another fix for the process file name in stat/status

Hi, attached there is a new patch for procfs to improve again the file name in stat/status files for PIDs. Basically, it just considers only the first word in case the process name has more (e.g. when it changed its own). Thanks, -- Pino Toscano From ebf2b049ea6963026766763df1697467f5806327

Re: Status report on the conversion of the Hurd to pthreads

On Tue, Aug 21, 2012 at 09:44:43PM +0200, Richard Braun wrote: > Debian packages are available for testing using this repository : > deb http://ftp.sceen.net/debian-hurd experimental/ > deb-src http://ftp.sceen.net/debian-hurd experimental/ > > Upgrade glibc packages first, then the hurd and netdd

Status report on the conversion of the Hurd to pthreads

Hello, With the help of Barry deFreese and Thomas DiModica, a few machines are currently running Hurd systems with no code dependency on the previous cthreads library. Concerning upstream code, the appropriate branches can be found there : http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbr

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sun 08 Apr 2012 01:28:48 +0300, a écrit : >> No, it isn't bogus and should work, but as it is hack that relies on >> implementation and how it works is not obvious (at least from my point >> of view), I decided to disable it. Do you think that it shoul

Re: tmpfs status

Maksym Planeta, le Sun 08 Apr 2012 01:28:48 +0300, a écrit : > No, it isn't bogus and should work, but as it is hack that relies on > implementation and how it works is not obvious (at least from my point > of view), I decided to disable it. Do you think that it should be > returned? It depends ho

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sun 08 Apr 2012 00:48:18 +0300, a écrit : >> > Existing conditions, agreed. But the conditions you introduce are about >> > one-level only. >> >> Really, but I can replace 3 conditions from the beginning of commit with >> one. Would it fit? > > That

Re: tmpfs status

Maksym Planeta, le Sun 08 Apr 2012 00:48:18 +0300, a écrit : > > Existing conditions, agreed. But the conditions you introduce are about > > one-level only. > > Really, but I can replace 3 conditions from the beginning of commit with > one. Would it fit? That would be simpler, yes. > >> Also yo

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sun 08 Apr 2012 00:17:43 +0300, a écrit : >> Samuel Thibault writes: >> > Maksym Planeta, le Sat 07 Apr 2012 23:20:13 +0300, a écrit : >> >> > No: as I said, allocate an empty map, so that the existing code can poke >> >> > at it without testing for i

Re: tmpfs status

Maksym Planeta, le Sun 08 Apr 2012 00:17:43 +0300, a écrit : > Samuel Thibault writes: > > Maksym Planeta, le Sat 07 Apr 2012 23:20:13 +0300, a écrit : > >> > No: as I said, allocate an empty map, so that the existing code can poke > >> > at it without testing for its presence or not. > >> > > >>

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sat 07 Apr 2012 23:20:13 +0300, a écrit : >> > No: as I said, allocate an empty map, so that the existing code can poke >> > at it without testing for its presence or not. >> > >> >> Purpose of this conditions is checking whether map (or submap) is >>

Re: tmpfs status

Maksym Planeta, le Sat 07 Apr 2012 23:20:13 +0300, a écrit : > > No: as I said, allocate an empty map, so that the existing code can poke > > at it without testing for its presence or not. > > > >> Purpose of this conditions is checking whether map (or submap) is > >> already empty. > > > > Not emp

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sat 07 Apr 2012 21:42:04 +0300, a écrit : >> Samuel Thibault writes: >> >> > Maksym Planeta, le Sat 07 Apr 2012 19:51:56 +0300, a écrit : >> >> Here is initialization code from pager_alloc(): >> >> if (INDIRECT_PAGEMAP(size)) { >> >>

Re: tmpfs status

Maksym Planeta, le Sat 07 Apr 2012 21:42:04 +0300, a écrit : > Samuel Thibault writes: > > > Maksym Planeta, le Sat 07 Apr 2012 19:51:56 +0300, a écrit : > >> Here is initialization code from pager_alloc(): > >>if (INDIRECT_PAGEMAP(size)) { > >>alloc_size = INDIREC

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Sat 07 Apr 2012 19:51:56 +0300, a écrit : >> Here is initialization code from pager_alloc(): >> if (INDIRECT_PAGEMAP(size)) { >> alloc_size = INDIRECT_PAGEMAP_SIZE(size); >> init_value = (dp_map_t)

Re: tmpfs status

Maksym Planeta, le Sat 07 Apr 2012 19:51:56 +0300, a écrit : > Here is initialization code from pager_alloc(): > if (INDIRECT_PAGEMAP(size)) { > alloc_size = INDIRECT_PAGEMAP_SIZE(size); > init_value = (dp_map_t)0; > > And from pager_extend

Re: tmpfs status

Samuel Thibault writes: > >> >> Correct errors in default pager and make it work with tmpfs. >> > >> > That needs more explanation about how it works. >> > >> >> This is quite a big commit and I made several things there: > > So it should be broken down in several commits. > OK. >> >> Take into

Re: tmpfs status

Maksym Planeta, le Wed 28 Mar 2012 22:40:22 +0300, a écrit : > Samuel Thibault writes: > > > Thomas Schwinge, le Mon 26 Mar 2012 22:24:55 +0200, a écrit : > >> > 1. > >> > http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/master > >> > > >> > >> Someone to review the patche

Re: tmpfs status

Maksym Planeta, le Sat 31 Mar 2012 12:07:13 +0300, a écrit : > >> > I don't see an "initial content" option in tmpfs. That would be very > >> > useful, by e.g. providing a .tgz archive to be untarred at translator > >> > creation. > >> > >> Nice feature, but couldn't it be implemented just untarri

Re: tmpfs status

Samuel Thibault writes: > Maksym Planeta, le Wed 28 Mar 2012 20:42:07 +0300, a écrit : >> Samuel Thibault writes: >> >> > Ideally you should try to put a whole Hurd system on it, so >> > we can use it for liveCD and installer. >> >> Do you mean something like mounting ext2fs readonly and moun

Re: tmpfs status

Thomas Schwinge writes: > Hi! > > On Wed, 28 Mar 2012 23:41:57 +0300, Maksym Planeta > wrote: >> Thomas Schwinge writes: >> > On Wed, 28 Mar 2012 22:40:22 +0300, Maksym Planeta >> > wrote: >> >> Samuel Thibault writes: >> >> >> >> > Thomas Schwinge, le Mon 26 Mar 2012 22:24:55 +0200, a écr

Re: tmpfs status

Hi! On Wed, 28 Mar 2012 23:41:57 +0300, Maksym Planeta wrote: > Thomas Schwinge writes: > > On Wed, 28 Mar 2012 22:40:22 +0300, Maksym Planeta > > wrote: > >> Samuel Thibault writes: > >> > >> > Thomas Schwinge, le Mon 26 Mar 2012 22:24:55 +0200, a écrit : > >> >> > 1. > >> >> > http://git

Re: tmpfs status

Hi! On Wed, 28 Mar 2012 22:40:22 +0300, Maksym Planeta wrote: > Samuel Thibault writes: > > > Thomas Schwinge, le Mon 26 Mar 2012 22:24:55 +0200, a écrit : > >> > 1. > >> > http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/master > >> > > >> > >> Someone to review the pa

Re: tmpfs status

> Ideally, a type of archive that is able to store translators. I don't > know whether there are any. Some other way would be to just use ext2fs > and cp its content before throwing it away. Anything that uses the xattr interfaces and stores all that data ought to work--it's just setting the gnu.t

Re: tmpfs status

Samuel Thibault writes: > Thomas Schwinge, le Mon 26 Mar 2012 22:24:55 +0200, a écrit : >> > 1. >> > http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/master >> > >> >> Someone to review the patches... :-/ > > Just a few comments. > >> Fix auto-terminating of tmpfs due to

Re: tmpfs status

Thomas Schwinge writes: > Hi! > > On Wed, 28 Mar 2012 22:40:22 +0300, Maksym Planeta > wrote: >> Samuel Thibault writes: >> >> > Thomas Schwinge, le Mon 26 Mar 2012 22:24:55 +0200, a écrit : >> >> > 1. >> >> > http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/master >> >>

Re: tmpfs status

Maksym Planeta, le Wed 28 Mar 2012 20:42:07 +0300, a écrit : > Samuel Thibault writes: > > > Ideally you should try to put a whole Hurd system on it, so > > we can use it for liveCD and installer. > > Do you mean something like mounting ext2fs readonly and mounting tmpfs > on top of it using un

Re: tmpfs status

Samuel Thibault writes: > Ideally you should try to put a whole Hurd system on it, so > we can use it for liveCD and installer. Do you mean something like mounting ext2fs readonly and mounting tmpfs on top of it using unionfs? If so, I'll try to do it, but a bit later. > I don't see an "initia

Re: tmpfs status

Maksym Planeta, le Wed 28 Mar 2012 00:36:07 +0300, a écrit : > Samuel Thibault writes: > > > Please try to set passive and active translators etc. on it. > I've tried it earlier and didn't find any issues, except those, that > I've already corrected. Ok, good. Ideally you should try to put a w

Re: tmpfs status

Samuel Thibault writes: > Please try to set passive and active translators etc. on it. I've tried it earlier and didn't find any issues, except those, that I've already corrected. > IIRC somebody was trying a filesystem testsuite? It was me :) I was trying fsx [1]. It performs random IO operat

Re: tmpfs status

Thomas Schwinge writes: > Did you reboot the machine after every test? > New results are following: dpkg-buildpackage ramfs+ext2fs 50m5s ext2fs

Re: tmpfs status

Thomas Schwinge writes: >> I also made some performance tests. First was measuring time of working >> command "apt-get source elinks". Approximately half time of working of >> this command takes extracting files from archive. Second test was >> measuring time for command "dpkg-buildpackage -b -

Re: tmpfs status

Maksym Planeta, le Mon 26 Mar 2012 21:31:45 +0300, a écrit : > I'm currently working on getting tmpfs work on the Hurd. I already asked > on IRC to make or suggest some test for tmpfs. Last time Thomas Schwinge > suggested me to compile packages and thanks to that a found some bugs. > Now they ar

Re: tmpfs status

Thomas Schwinge, le Mon 26 Mar 2012 22:24:55 +0200, a écrit : > > 1. > > http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/master > > Someone to review the patches... :-/ Just a few comments. > Fix auto-terminating of tmpfs due to idle. Err, really? I'd rather not see my

Re: tmpfs status

Hi! On Mon, 26 Mar 2012 21:31:45 +0300, Maksym Planeta wrote: > I'm currently working on getting tmpfs work on the Hurd. I already asked > on IRC to make or suggest some test for tmpfs. Last time Thomas Schwinge > suggested me to compile packages and thanks to that a found some bugs. > Now the

tmpfs status

Hello, I'm currently working on getting tmpfs work on the Hurd. I already asked on IRC to make or suggest some test for tmpfs. Last time Thomas Schwinge suggested me to compile packages and thanks to that a found some bugs. Now they are seems to be fixed, so I ask once more to make/suggest some

Re: [PATCH] procfs: fix process file name in stat/status

Pino Toscano, le Sat 14 Jan 2012 15:12:43 +0100, a écrit : > Attached there is a patch (for the jkoenig/master branch) to fix this > behaviour in per-process `stat' and `status' files. Applied, thanks! Samuel

[PATCH] procfs: fix process file name in stat/status

/master branch) to fix this behaviour in per-process `stat' and `status' files. Thanks, -- Pino Toscano From 3eec2e26d3c4cf83004eed079f0455ed4485095e Mon Sep 17 00:00:00 2001 From: Pino Toscano Date: Sat, 14 Jan 2012 14:47:58 +0100 Subject: [PATCH] PID stat/status: show only the fil

Re: Fwd: The status of dde linux26 in Hurd

Hi, On 10-1-28 上午12:24, Samuel Thibault wrote: > Da Zheng, le Wed 27 Jan 2010 19:17:57 +0800, a écrit : >> Next step is to develop Mach device interface on the top of dde linux26. It >> shouldn't be difficult for the network device as I have done that before. I >> should try some types of devices

Re: Fwd: The status of dde linux26 in Hurd

Da Zheng, le Wed 27 Jan 2010 19:17:57 +0800, a écrit : > Next step is to develop Mach device interface on the top of dde linux26. It > shouldn't be difficult for the network device as I have done that before. I > should try some types of devices other than NIC. Some suggestions about it? Hard disk

Fwd: The status of dde linux26 in Hurd

sorry, send it to a wrong mailing list. Original Message Subject: The status of dde linux26 in Hurd Date: Wed, 27 Jan 2010 18:59:36 +0800 From: Da Zheng To: help-h...@gnu.org Hi, Porting dde linux26 to the Hurd works smoothly. Currently pcnet32 driver can work in it. I

Re: status

Hi, On Sun, Nov 09, 2008 at 11:52:01AM +0100, Michael Banck wrote: > The Hurd project said it would move to L4, this project has failed and > people are still confused about this several years later. We should > learn from this and not make any announcements or predictions on how > or when the H

Re: status

Am Sonntag 09 November 2008 11:52:01 schrieb Michael Banck: > You can have your hopes however you want, but it is not very productive > to hype up Viengoos as the next microkernel at this point. Neal has I'll try to be more clear that these are only my personal hopes next time. I thought that a

Re: status

Arne, On Sun, Nov 09, 2008 at 11:26:24AM +0100, Arne Babenhauserheide wrote: > If Viengoos fullfills the hopes I have in it since I read the paper from > Neal, > then it's likely that the GNU/Hurd will be ported to it. You can have your hopes however you want, but it is not very productive to

Re: status

; > could someone please enlighten me on the current status of the GNU/Hurd > > > servers/kernel. Are the developers still looking to replace the Mach > > > kernel with the Coyotos microkernel? > > > > Currently they are first improving the Mach version, but Neal

Re: status

On Saturday 08 November 2008 04:31:27 Gnu Logic wrote: > could someone please enlighten me on the current status of the GNU/Hurd > servers/kernel. Are the developers still looking to replace the Mach > kernel with the Coyotos microkernel? Currently they are first improving the Mach ver

status

could someone please enlighten me on the current status of the GNU/Hurd servers/kernel. Are the developers still looking to replace the Mach kernel with the Coyotos microkernel?

Re: Tracking development status (was: GSoC application deadline passed)

Scribit [EMAIL PROTECTED] dies 18/03/2008 hora 12:31: > Well, the idea of an aggregator was brought up before. But I actually > like the idea of a shared blog more. The aggregator has less administraive burden and more flexibility. You don't have to manage accounts and access to a shared ressource

Tracking development status (was: GSoC application deadline passed)

Hi, On Mon, Mar 17, 2008 at 10:37:56AM +0100, Arne Babenhauserheide wrote: > El Friday, 14 de March de 2008 16:23:34 Michael Banck escribió: > Else, a GNU Hurd news aggregator might be useful. > > There are many Hurd groups, so maybe an RSS feed which aggregates all > rss feeds from the differe

  1   2   3   >