Re: Testing requested for the next version of GNU Mach

newer versions of GRUB place more boot data, or align them differently, and that we neeed to do a better job at freeing boot data. I'm also not sure why my changes affect that... What's your versions of GRUB (please don't say "latest", always state the IDs explicitely) ? -- Richard Braun

Re: Update: Failing tests: Re: RFC: [PATCH] SCM_CREDS support

ep for synchronization is always wrong. -- Richard Braun

Re: Update: Failing tests: Re: RFC: [PATCH] SCM_CREDS support

On Mon, Mar 14, 2016 at 02:35:13PM +0100, Svante Signell wrote: > On Mon, 2016-03-14 at 14:23 +0100, Richard Braun wrote: > > On Mon, Mar 14, 2016 at 02:16:17PM +0100, Samuel Thibault wrote: > > > Svante Signell, on Mon 14 Mar 2016 12:20:18 +0100, wrote: > > > >

Re: Testing requested for the next version of GNU Mach

GS allowed gnumach to boot > successfully and resulted in this: > > vm_page: DMA: pages: 4080 (15M), free: 2053 (8M) > > The difference may be because GRUB apparently passes the multiboot ELF > info, while QEMU does not. I'll just make sure to disable debug flags > when b

Re: Testing requested for the next version of GNU Mach

On Tue, Mar 15, 2016 at 12:32:43AM +0100, Samuel Thibault wrote: > Richard Braun, on Mon 14 Mar 2016 23:37:33 +0100, wrote: > > On Mon, Mar 14, 2016 at 06:27:24PM -0400, David Michael wrote: > > > After poking around a bit more, it seems that the space is eaten by > > >

Re: Shared mappings not being inherited by children

an additional 'vm_inherit' if the user > specified > a shared mapping. > > What do you guys think? I completely agree with using vm_map unconditionnally and I'm glad to see someone take the time to work on these things. -- Richard Braun

Re: Build times of hurd and glibc for different versions of gnumach, hurd and glibc

point, we should provide a 64-bits capable kernel caching interface, and write an ext4fs server. I'll see if I can spend some time on this after high memory. -- Richard Braun

Re: Build times of hurd and glibc for different versions of gnumach, hurd and glibc

d, I just want to make this clear for people who haven't followed. -- Richard Braun

Re: RFC: Lightweight synchronization mechanism for gnumach v3

bpthread :) I agree, we shouldn't cling on our current implementation, and I'm sure we can deal with the bugs in short time with our experience and Agustina's help. -- Richard Braun

Re: Build times of hurd and glibc for different versions of gnumach, hurd and glibc

last GSoC to back VM objects with radix trees, which involves turning a lot of simple locks into general locks, so it's a bit tricky. -- Richard Braun

Re: Build times of hurd and glibc for different versions of gnumach, hurd and glibc

ions at worst O(n). If anyone feels like doing that little task, enjoy yourself. Otherwise, I'll probably do it, when I have some time, as usual. -- Richard Braun [1] http://git.sceen.net/rbraun/x15.git/blob/HEAD:/vm/vm_map.c

Re: Build times of hurd and glibc for different versions of gnumach, hurd and glibc

On Wed, Apr 20, 2016 at 11:44:36AM +0200, Samuel Thibault wrote: > Richard Braun, on Wed 20 Apr 2016 11:40:39 +0200, wrote: > > I wrote an incomplete vm_map_enter in X15 [1] that should be helpful. > > In addition to a free hint pointer, it uses the red-black tree, making > &g

Re: RFC: Lightweight synchronization mechanism for gnumach v3

;t, exactly because of the performance overhead of our current mutexes. -- Richard Braun

Re: Build times of hurd and glibc for different versions of gnumach, hurd and glibc

On Wed, Apr 20, 2016 at 11:40:39AM +0200, Richard Braun wrote: > I wrote an incomplete vm_map_enter in X15 [1] that should be helpful. > In addition to a free hint pointer, it uses the red-black tree, making > all allocations at worst O(n). If anyone feels like doing that little >

Re: [ PATCH ] Replace glibc spin-locks with gsync-based locks

ce, but for now, it's still recommended. The real issue here in my opinion is the low amount of memory. We know our swapping code is low quality, so adding memory (2g at most currently) makes it a lot less likely to hit a "swapping deadlock". -- Richard Braun

Re: gnumach 1.7 issue

uggy > or exposing other bugs. I've just pushed c89365 which fixes the issue. -- Richard Braun

[bug #48372] read with size 0 from fifo blocks

Follow-up Comment #3, bug #48372 (project hurd): See http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=293e86998748bae2d7a8179ad198ec3452f0d472 ___ Reply to this item at: ___

[PATCH] VM: fix pageout-related deadlock

* vm/vm_map.c (_vm_map_entry_create): Temporarily set the current thread as VM privileged. --- vm/vm_map.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/vm/vm_map.c b/vm/vm_map.c index 4490878..5d544c4 100644 --- a/vm/vm_map.c +++ b/vm/vm_map.c @@ -240,8 +240,26 @@ vm_map

Re: [PATCH] VM: fix pageout-related deadlock

On Sat, Jul 23, 2016 at 12:58:59AM +0200, Richard Braun wrote: > * vm/vm_map.c (_vm_map_entry_create): Temporarily set the current thread > as VM privileged. If nobody objects to the solution proposed, I'll push this patch on master. -- Richard Braun

Re: Hurd on a cluster computer

which is probably the closest example to what would be relatively easy to achieve on the Hurd. It doesn't provide a complete SSI system but allows mostly transparent access to remote resources, like Plan9 and other similar systems would, in a way that is much closer to how the Hurd on top of Mach would do. -- Richard Braun

Re: Hurd on a cluster computer

On Fri, Jul 29, 2016 at 07:34:39PM -1000, Brent W. Baccala wrote: > Any recent attempts to get netmsg running on GNU Mach? NORMA? None, recent or otherwise. -- Richard Braun

Re: Hurd on a cluster computer

ion on gnu.org could use an update by the way. -- Richard Braun [1] http://darnassus.sceen.net/~teythoon/mach-protected-payloads/Receive-Rights.html

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

st you don't do that, since you'll basically replace the pflocal instance for all the system, which might break already running processes. Use the remap translator instead, which is one of the things the Hurd design allows you to do easily. See /bin/remap to easily set one. -- Richard Braun

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

t; filesystem, it is started "outside" of the remap environment. I belive > 2/ is what happens here. Why not start the translator from the remapped environment too ? -- Richard Braun

Re: [PATCH] [hurd] pflocal/socket.c: Support MSG_DONTWAIT in pflocal send/recv

On Mon, Aug 08, 2016 at 04:54:47PM +0200, Justus Winter wrote: > Richard Braun writes: > > Why not start the translator from the remapped environment too ? > > No reason, but this has to be implemented. I started working on a > library for writing such chrooting translat

Re: Fwd: Hurd shutdown problems

t I've just noticed that we don't request page-aligned modules from the boot loader (see MULTIBOOT_FLAGS in boothdr.S), and at some point, late during the boot process, module data are freed using (see free_bootstrap_pages in bootstrap.c). This might explain the corruptions. -- Richard Braun

Re: Fwd: Hurd shutdown problems

On Wed, Aug 10, 2016 at 04:26:35PM +0200, Richard Braun wrote: > the boot loader (see MULTIBOOT_FLAGS in boothdr.S), and at > some point, late during the boot process, module data are freed > using (see free_bootstrap_pages in bootstrap.c). This might Using vm_page_manage(). -- Richard Braun

Re: Fwd: Hurd shutdown problems

calling vm_page_manage. To properly answer your question, step 1/ is what looks at the boot data (biosmem_find_boot_data) so that the resulting heap boundaries completely exclude any. -- Richard Braun

Re: Fwd: Hurd shutdown problems

f0x00116000 vaddr 0x81115000 paddr 0x01115000 align 2**12 > filesz 0xd151 memsz 0x00039384 flags rw- > > It seems biosmem's heap doesn't even exclude the kernel data?! Could be a mistake with regard to the linker script. -- Richard Braun

Re: Fwd: Hurd shutdown problems

On Fri, Aug 12, 2016 at 07:57:10PM +0200, Richard Braun wrote: > On Fri, Aug 12, 2016 at 05:17:26PM +0200, Samuel Thibault wrote: > > biosmem: heap: 114f000-7a00 > > > > and objdump shows: > > > > LOAD off0x1000 vaddr 0x8100 paddr 0x010

Re: Fwd: Hurd shutdown problems

X15... I guess I didn't have the case where a segment didn't clip with the heap until now, in which case, instead of being completely loaded as available, it should be loaded as reserved, and only later made available. -- Richard Braun

Re: Fwd: Hurd shutdown problems

On Fri, Aug 12, 2016 at 09:07:48PM +0200, Samuel Thibault wrote: > > I'm curious: what makes it definitely wrong on a PC ? > > A PC has BIOS stuff between A and 10. Right, misread a 0 again. -- Richard Braun

Re: Simple contribution please?

makes a huge difference in virtualized guests compared to C-based ones because of vmenter/vmexit. -- Richard Braun

Re: Simple contribution please?

On Fri, Aug 12, 2016 at 09:16:02PM +0200, Richard Braun wrote: > Note that it's not that "simple" since we'd like implementations that > aren't naive, i.e. assembly with rep instructions. In particular, it > makes a huge difference in virtualized guests com

Re: Simple contribution please?

On Fri, Aug 12, 2016 at 09:21:11PM +0200, Samuel Thibault wrote: > Richard Braun, on Fri 12 Aug 2016 21:16:02 +0200, wrote: > > On Fri, Aug 12, 2016 at 07:57:48PM +0200, Samuel Thibault wrote: > > > It becomes more and more clear that we shouldn't steal functions from >

Re: Simple contribution please?

't run > str functions on memory-mapped devices anyway...) Actually, assembly isn't used for these functions. Take a look at the ARCH_STRING_XXX macros at the beginning of the file. These are used in X15 to select between machine specific and generic versions, which we could also use lat

Re: Simple contribution please?

On Wed, Aug 17, 2016 at 08:53:51AM +0200, Samuel Thibault wrote: > - also, in strstr, is it really better to use strncmp instead of strcmp? If I understand correctly, strcmp wouldn't behave right since it compares the terminating null byte. -- Richard Braun

Re: Simple contribution please?

mory compiler barrier at the > function call anyway). My thinking was rather to let gcc know that memory is being read so that it wouldn't generate instructions that might change it in parallel, although I don't think it's possible considering the instructions actually used. -- Richard Braun

Re: netmsg

uthenticate. That's a very interesting problem indeed, not sure how to fix it. -- Richard Braun

Re: [GSoC] Implement xattr Support Update

iew and merge it. Congratulations :) -- Richard Braun

Re: exec server behavior

behaviour. I started thinking about these only a couple of weeks ago, and so far the only solutions my limited brain can come up with is to either use the client context (by perhaps passing its root) but that could cause security issues, or have a third-party like auth (or proc or whatever) store enough of this context that the server can use it. -- Richard Braun

Re: exec server behavior

On Thu, Aug 25, 2016 at 12:20:45PM +0200, Richard Braun wrote: > I started thinking about these only a couple of weeks ago, and so far > the only solutions my limited brain can come up with is to either use > the client context (by perhaps passing its root) but that could cause > sec

Re: Denial of service attack via libpager

_avoid_ mmap, and copy the data in instead, possibly (and in this case probably) with zero-copy. Finally, I fail to see how making libpager handle multiple clients will solve that issue. The only client should be the local kernel, right ? -- Richard Braun

Re: Denial of service attack via libpager

a good thing that any unprivileged client is allowed to perform memory object management calls... -- Richard Braun

Re: Denial of service attack via libpager

he file being mapped more than once I suppose, right ? -- Richard Braun

Re: Denial of service attack via libpager

On Mon, Aug 29, 2016 at 11:20:47AM +0200, Richard Braun wrote: > In addition, I've just thought about something else : if we handle > multiple clients, how do we make sure that two kernels, caching the > same file, don't just completely corrupt its content ? We'd need >

Re: Denial of service attack via libpager

On Mon, Aug 29, 2016 at 03:58:29PM -1000, Brent W. Baccala wrote: > On Sun, Aug 28, 2016 at 11:15 PM, Richard Braun wrote: > > OK, this comes from the fact that io_map directly provides memory > > objects indeed... Do we actually want to pass them around ? How >

Re: netmsg can now exec files (sort of)

p-less case more efficient by carefully copying the data. I didn't insist on COW zero-copy for no reason. -- Richard Braun

Re: mach_msg blocking on call to vm_map

lowing the transaction to be interrupted (usually with a - hardcoded ? check how glibc handles Ctrl-C/SIGINT during an RPC - 3 seconds grace delay before brutal interruption) may be the only things required to make the behaviour comply with "Hurdish expectations". -- Richard Braun

Re: mach_msg blocking on call to vm_map

On Thu, Sep 01, 2016 at 11:54:20AM -1000, Brent W. Baccala wrote: > On Thu, Sep 1, 2016 at 10:28 AM, Richard Braun wrote: > > I completely disagree. > > Thank you, Richard. Really! Thank you for disagreeing. Now we can have a > good discussion about this! This is how it

Re: mach_msg blocking on call to vm_map

e passing, not the server operation itself. In this case, the server is the kernel, and the vm_map call itself has no associated timeout. In my opinion, your network server should do what all servers do, i.e. dedicate a thread to the processing of a complete RPC and spawn as many as necessary when receiving messages. -- Richard Braun

Re: mach_msg blocking on call to vm_map

On Fri, Sep 02, 2016 at 01:18:26AM +0200, Richard Braun wrote: > In my opinion, your network server should do what all servers do, > i.e. dedicate a thread to the processing of a complete RPC and spawn > as many as necessary when receiving messages. At least for RPCs. Is there a wa

Re: mach_msg blocking on call to vm_map

ing back to the idea of using a thread pool. If a mach_msg call succeeds, good for you, grab the next message. If not, at least you're not affecting other users, except maybe through a denial of service, the only kind of security issue inevitable with a design where servers allocate from their own resources on behalf of their clients. That's when you get to things like quotas and resource limits. -- Richard Braun

Re: RFC: Revised authentication protocol

authentication issue. > > Comments? I'm not completely familiar with the inner workings of the auth server but they look easy enough to imagine. Still, an opinion from someone more familiar with it like Olaf would be great. >From what I've read, it looks good. I can't imagine a scenario that would defeat your assertions. -- Richard Braun

Re: firmlink deleting files on boot / interpretation of find -xdev switch

;passive translators" to more accurately reflect what they truely are. The solution, whatever it is, should focus only on determining whether a server can be trusted or not. This should affect everything (servers, (active) translators and translator records). -- Richard Braun

Re: firmlink deleting files on boot / interpretation of find -xdev switch

of it. What I want is to safely extend that trust to other users (root and self should be default), and again, to other properties (like POSIX style capabilities). And I'd like to merely avoid contact with servers that aren't part of this trust computing base. We'd also have to make sure that remove()/unlink()/rmdir() don't cross the file system into the untrusted translator. -- Richard Braun

Re: firmlink deleting files on boot / interpretation of find -xdev switch

of his own processes? Something like adding > directories to your own PATH, but this would apply to translators running > under different UIDs, and not just programs that you started yourself? My current idea is something like Plan9 factotum, an agent that would be used by any program, client or server, to validate that it's safe to communicate through a given port. -- Richard Braun

Re: firmlink deleting files on boot / interpretation of find -xdev switch

don't know if that's already the case or not since Justus' work on /proc/mounts. The work required here is to rely on the parent to report whether a node is a separate file system. This could also break programs assuming a file system is a directory if the attached translator presents itself as something else. -- Richard Braun

Re: RFC: Revised authentication protocol

vers -- > including auth -- rather than separate ones for each node?... I would think it best to make that a distributed process. -- Richard Braun

Re: behavior of NO SENDERS notifications when receive rights move

rtainly very limited and local. The design of the system simply doesn't need that feature. I completely understand the hassle you'd have to go through for this and I don't really see the benefit, so my opinion would be go ahead. -- Richard Braun

Re: Time for another round of releases

nd GNU/Hurd, modulo the > Hurd-specific patches. The real problem is that we still have nothing about mlockall... Until we have, there is really not much to talk about. -- Richard Braun

Re: behavior of NO SENDERS notifications when receive rights move

ltimate recipient can see which one > was used.) This seems overly complicated and error-prone. Besides, I still don't understand the issue that MACH_SEND_LIFO would solve... -- Richard Braun

Re: libpager multi-client support

lexity in understanding and following the code. You should either go with C for excellent control, or another higher level langguage for e.g. user interfaces and tasks that don't require the highest performance. I really don't think the problem you describe would be so hard to solve in

Re: libpager multi-client support

aying it's not that hard. -- Richard Braun

Re: Time for another round of releases

be OK to move the > release date towards end of November? (Yay, one more month for getting > stuff finished for inclusion...) ;'-\ Congratulations :-). -- Richard Braun

Re: libdiskfs: fix removal of socket nodes

On Thu, Oct 27, 2016 at 05:49:17PM +0200, Samuel Thibault wrote: > Richard, in 5ab5d98fa515cd19a64e8d5868fcbae85eec9dc5 ('libdiskfs: fix > removal of socket nodes') you patched diskfs_nput. Doesn't the fix need > to be done on diskfs_nrele too? I'd say so, yes. -- Richard Braun

Re: aptitude not working

such problem. On the other hand, the Hurd may be hanging. Using aptitude can lead to large memory usage, which can increase swap usage, and fill kernel memory (in older kernels at least). So, what's your version of GNU Mach ? And how much memory do you have on your system ? -- Richard Braun

Re: aptitude not working

On Mon, Nov 07, 2016 at 02:49:35PM +0100, Richard Braun wrote: > So, what's your version of GNU Mach ? And how much memory do you have > on your system ? We also know network can just randomly hang because of bugs in the netdde server. -- Richard Braun

Re: aptitude not working

here is > nothing to download and it will hang again. Are you logged in locally or through SSH ? -- Richard Braun

Re: aptitude not working

e) was very recently fixed [1] with regard to paging. -- Richard Braun [1] https://git.sceen.net/hurd/hurd.git/commit/?id=81fb68fee81769d81c373e3af5a508d706b7e3d6

Re: aptitude not working

d upgrade without too much trouble with aptitude. I use it on all my machines, Linux and Hurd, and never have such issues. -- Richard Braun

Re: aptitude not working

something wrong, I guess it is not in the usage of aptitude > itself, but more in something in my HURD setup? I don't think you're doing something "wrong", I think we (the developers) know the system enough to avoid most of the caveats. But yes, it's probably caused by a Hurd defect. -- Richard Braun

Re: aptitude not working

e default mach console, with a single terminal only. -- Richard Braun

Re: aptitude not working

On Mon, Nov 14, 2016 at 04:52:25PM +0100, Richard Braun wrote: > > (btw: can you read out these values later on, with a command similar to > > dmesg? pausing VirtualBOX and typing out things is boring) Ah, by the way, practically none of us run the Hurd on VirtualBox, and it'

Re: aptitude not working

, it quits and I see the on the console. > >I've seen this on Virtualbox, but now i have it on qemu with the same > >behavior. > > the behaviour is similar to mine then. I never use the curse based interface of aptitude. -- Richard Braun

Re: Unreclaimed swap space upon process termination?

ble to correctly reclaim these pages in the past, but now there are a lot more of them. -- Richard Braun

Re: Unreclaimed swap space upon process termination?

he problem is caused by the lack of threshold on the number of dirty pages. -- Richard Braun

Re: port leak in select

hose, add deb http://ftp.sceen.net/debian sid main to sources.list, and add the GPG key D50E6AD4 to APT. -- Richard Braun

Re: port leak in select

On Fri, Dec 02, 2016 at 10:43:04AM +0100, Samuel Thibault wrote: > Or simply > > (d[i].reply_port != MACH_PORT_NULL)) Aren't there cases where an entry could remain uninitialized ? -- Richard Braun

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

t is likely to fix the issue soon. Unless you really want to work on those red-black trees, stop pinging about this issue. -- Richard Braun [1] https://lwn.net/Articles/673724/ [2] https://git.sceen.net/hurd/gnumach.git/commit/?id=1db202eb8406785500f1bc3ceef7868566e416a1

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

a severe bug that made it very slow [1]. What would I have done ? Well I fixed it [2], a work of over a year because it required the Hurd code to switch from its native cthreads to pthreads [3]. I dare you to do the same. -- Richard Braun [1] https://www.gnu.org/softw

Stupid drama with Svante Signell

t another Svante screw up. -- Richard Braun

Re: panic: pmap_page_protect removing a wired page

h kernels as packaged by Debian. This was fixed by 1aa4ed6aaf69002b3bb7daed49cea8fa71536b66. -- Richard Braun

Re: [GSoC 2017] Multithreading

e thread. Cancellability and interruptibility are two different things. In particular, note how POSIX explicitely mentions that "These functions shall not return an error code of [EINTR]." -- Richard Braun

Re: multi page memory object operations

k isn't trivial, IOW it really needs careful review. -- Richard Braun

Re: [GSoC 2017] LwIP translator

On Sat, Aug 26, 2017 at 09:38:39AM +0200, Joan Lledó wrote: > The Google Summer of Code is about to end and it is time to summarize my work > on the lwip translator. Excellent work, one of the best GSoC projects I've seen. -- Richard Braun

Re: gnumach - Page fault error

linux/dev/glue/block.c:device_write, where the local vm_map_copy object may be discarded while still uninitialized. Probably unrelated but still noteworthy. -- Richard Braun

Re: gnumach - Page fault error

On Thu, Nov 09, 2017 at 10:34:33AM +0100, Samuel Thibault wrote: > Jens Arm, on jeu. 09 nov. 2017 08:56:21 +0100, wrote: > > Sorry for the late answer. > > This fix fixes the crashes. > > Cool :) Nice catch :). -- Richard Braun

Re: race condition destroying condition variables

7;re normally really interested in is releasing this parent object, including destroying the mutex, which means you also have to wait for all threads to unlock it. One common way to deal with this is reference counters on the parent object. -- Richard Braun

Re: Enable SMP support

mily. The idea is to create an eax variable with the value 1 in C, pass that to the inline assembly expression with the appropriate constraint, and do something similar for the returned value in ebx, and then extract bh from it. -- Richard Braun [1] https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/Machine-Constraints.html#Machine-Constraints

Re: Enable SMP support

On Fri, Jun 15, 2018 at 07:18:55PM +0200, Richard Braun wrote: > On Fri, Jun 15, 2018 at 06:27:21PM +0200, Almudena Garcia wrote: > > I'm trying to define the cpu_number() in multiprocessor. > > > > To do this, I tried to use CPUID assembly x86 instruction, to get the C

Re: Enable SMP support

efer to a per-processor area in memory, where the ID of the current processor can be found, among other things. See the cpu_id() function at [1] for a reasonably simple (but not naive) implementation. -- Richard Braun [1] https://git.sceen.net/rbraun/x15.git/tr

Re: Question about protected payloads

matching the one inside > the payload. > > Anyone has a hint on what could be happening here? I'm lost :( > > Reproducing this bug is easy: just install the liblwip0 package and > try to open a ssh connection to our lwip translator. Just to be sure, do you see what protected payloads are ? -- Richard Braun

Re: Question about protected payloads

bject from it, we use protected payloads, which are merely user-assigned arbitrary values associated to ports, to store the address of the associated object directly, and that's what you receive instead of the port name. -- Richard Braun

Re: Fwd: The GNU C Library version 2.28 is now available

On Wed, Aug 01, 2018 at 09:53:59AM +0200, Samuel Thibault wrote: > NEWS for version 2.28 > = > > [...] > > * Building and running on GNU/Hurd systems now works without out-of-tree > patches. I didn't think it would actually happen. Great work :). -- Richard Braun

Re: How do I learn the Hurd stuff?

're doing, and set yourself real-world goals like developing a project doing something that actually interests you. -- Richard Braun

Re: How do I learn the Hurd stuff?

On Thu, Aug 30, 2018 at 04:52:28PM +0200, Almudena Garcia wrote: > > But this solution would be specific to Intel chips? ie: this method of > > SMP wouldn't work on AMD or POWER right > > All x86 architecture, I think What on Earth are you talking about ? -- Richard Braun

Re: How do I learn the Hurd stuff?

. > > https://c9x.me/x86/html/file_module_x86_id_45.html > > https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.html What is "a newer implementation via hardware" ? Can you be very specific about what you're referring to ? -- Richard Braun

Re: How do I learn the Hurd stuff?

-developer-vol-3a-part-1-manual.html Oh, so it's merely runtime probing. -- Richard Braun

Re: How do I learn the Hurd stuff?

On Thu, Aug 30, 2018 at 06:15:28PM +0200, Almudena Garcia wrote: > It's not only a test. Obviously, It must start as a test, but I want to add > this to Hurd if runs. > > > > El jue., 30 ago. 2018 a las 18:02, Richard Braun () > escribió: > > > On Th

<    1   2   3   4   5   6   >