Re: Regarding meltdown/spectre

It's worth keeping in mind that there are very likely important security bugs far more dangerous than rowhammer-style attacks in Mach, let alone the Hurd. Security-critical applications should be pretty cautious. On Sat, Feb 3, 2018 at 7:18 AM Samuel Thibault wrote: >

Re: Canterbury Tales Prologue

Or just http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/hurd/fs.defs#n59 . On Thu, Mar 5, 2015 at 8:14 AM A. Fleckenstein afl...@inventati.org wrote: On Thu, Mar 05, 2015 at 08:20:16PM +1300, Philip Charles wrote: Where can I find this - I have tried. Phil. git clone

Re: Canterbury Tales Prologue

Where can you find what, exactly? On Wed, Mar 4, 2015 at 11:21 PM Philip Charles phil...@copyleft.co.nz wrote: On Thu, 2015-03-05 at 04:22 +, Thomas Bushnell, BSG wrote: It's not *quite* an excerpt. On Tue, Mar 3, 2015 at 5:41 AM A. Fleckenstein afl...@inventati.org wrote

Re: Canterbury Tales Prologue

It's not *quite* an excerpt. On Tue, Mar 3, 2015 at 5:41 AM A. Fleckenstein afl...@inventati.org wrote: In the hurd sources, hurd/hurd/fs.defs, line 59 begins a comment, the contents of which are an excerpt from the prologue of Geoffrey Chaucer's Canterbury Tales. Anyone know why this is?

Re: Many questions, mostly about mach-defpager

A wired thread (vm_wire) has special vm rules inside the kernel. It's got nothing to do with what you might expect (tying a cthread to a kernel thread). Thomas On Mon, Apr 30, 2012 at 4:30 PM, Thomas Thomas ricinw...@yahoo.com wrote: So, mach-defpager wires all of its threads. What exactly

Re: ext2fs kernel profiling: most of the time in thread management

2011/12/30 Jérémie Koenig j...@jk.fr.eu.org On Thu, Dec 29, 2011 at 1:25 AM, Samuel Thibault samuel.thiba...@gnu.org wrote: [...], but I believe it's still a bit revealing: I had already noticed that ext2fs spends most of its time in the kernel (like 90%), and it here seems we're spending

Re: GNUnet News: vfork and the signal race

Programs which depend on the special suspend-the-parent behavior of vfork were always regarded as buggy... Thomas On Fri, Nov 25, 2011 at 7:42 AM, Thomas Schwinge tho...@schwinge.namewrote: Hallo! On Thu, 24 Nov 2011 15:59:55 -, Planet GNU tschwinge+n...@gnu.org wrote: Many articles

Re: mach_msg fails to copy out-of-line data when length = 512MB

I think the fear is of resource exhaustion, but there are so many of those problems, this would not be the first place to look IMO. Thomas On Thu, Sep 22, 2011 at 4:29 PM, Roland McGrath rol...@hack.frob.comwrote: The whole point of OOL data is that it is relatively cheap to transfer huge

Re: Should diskfs_file_update be called in every io_write?

I think this could also create extra churn, by scheduling a lot of disk writes when a series of writes are done all at once to a single file. Traditionally, this is addressed by the every-30-seconds update task; there is no expectation of an indefinitely postponed write. However, much could be

Re: [PATCH v2 1/4] ftpfs/host.c: use NULL (instead of 0) for pointers

I agree with Samuel. The use of NULL for pointers in C can lead people to forget that C does not protect the types in this case. Thomas On Sat, Aug 20, 2011 at 9:24 AM, Samuel Thibault samuel.thiba...@gnu.orgwrote: Jonathan Neuschäfer, le Mon 15 Aug 2011 22:10:06 +0200, a écrit : *

Re: set_mtime/set_atime in term/users.c, really needed?

It's what Linux does at least. And Posix likely requires it. On Tue, Jul 26, 2011 at 4:52 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote: Hello, I've noticed that term/users.c calls set_atime/mtime for each and every io_write/read performed on a tty. This means for instance that each

Re: chroot sockets (was: Introducing the hardening-wrapper package)

Cheroot isn't supposed to change the namespace of Unix domain sockets in the case where the chroot shares a file with the main system. On Jun 2, 2011 6:56 PM, olafbuddenha...@gmx.net wrote: Hi, On Tue, May 31, 2011 at 09:35:32AM +0200, Samuel Thibault wrote: You just need another partition,

Re: Race condition (was problem) in Mach/Hurd?

Yes. Timers do create new threads to wait for the event in question, and then they send the signal in the normal way. On May 10, 2011 11:18 AM, Richard Braun rbr...@sceen.net wrote:

Re: XKB's keymaps for the Hurd console

Now you're just talking in crazy fantasy land. On Wed, Mar 23, 2011 at 3:39 AM, Michael Banck mba...@gmx.net wrote: On Tue, Mar 22, 2011 at 05:06:40PM -0500, Oz wrote: awsome sounds like i'll be playing some quake 3 mods in the near future on the hurd. I suggest you wait for Duke Nukem

Re: RPC to self with rendez-vous leading to duplicate port destroy

On Sun, Mar 13, 2011 at 7:25 PM, Samuel Thibault samuel.thiba...@gnu.orgwrote: olafbuddenha...@gmx.net, le Mon 14 Mar 2011 03:21:43 +0100, a écrit : There, the rendez-vous port is thus the same as the reply port obtained above, with the *same name*. - reauth() destroys the

Re: RPC to self with rendez-vous leading to duplicate port destroy

I think the second call to reauth should use a second, newly-created, rendezvous port. Why doesn't it? Thomas On Mar 13, 2011 5:44 PM, Samuel Thibault samuel.thiba...@gnu.org wrote: Hello, I've investigated a duplicate port destroy in ext2fs, what apparently happens is this: -

Re: [bug #32693] GNU/Hurd headers don't pass c++

This is not a bug. The headers are also not usable in pascal or fortran programs. Thomas On Mar 6, 2011 2:00 PM, Samuel Thibault invalid.nore...@gnu.org wrote: URL: http://savannah.gnu.org/bugs/?32693 Summary: GNU/Hurd headers don't pass c++ Project: The GNU Hurd Submitted by: sthibaul

Re: st_dev in struct stat

Yes, it's allowed. All names beginning with st_* are reserved if you include the relevant header files. rdfind has no business using such names. Thomas On Sun, Jan 9, 2011 at 4:11 PM, Pino Toscano toscano.p...@tiscali.itwrote: Hi, just looking at a recent build failure in Debian, rdfind.

Re: Migration threads

The idea of migrating threads is that it happens automatically on a synchronous rpc. Thomas On Sunday, December 26, 2010, Richard Braun rbr...@sceen.net wrote: Hello. From what I understand of the Hurd history, GNU Mach is based on Mach 4. I read that this version was intended to include the

Re: ED error code

Agreed. On Tue, Nov 2, 2010 at 7:52 AM, Michael Banck mba...@debian.org wrote: On Tue, Nov 02, 2010 at 11:30:28AM +0100, Manuel Menal wrote: On 02/11/2010 11:29, Samuel Thibault wrote: Manuel Menal, le Tue 02 Nov 2010 11:20:27 +0100, a écrit : “Macros that begin with E and a digit or E

Re: ED error code

On Sun, Oct 31, 2010 at 7:49 AM, Pino Toscano toscano.p...@tiscali.itwrote: Although having a reserved, generic error code macro might be useful(?), `ED' is a very generic identifier. For example, clang uses it in many parts of its code, which makes the build fail on GNU/Hurd. I think

Re: socket_send socket_recv fail when sending non-socket ports

Good catch. As Roland notes the old code here has the restart race bug. Also it was probably a leak because I think nothing here wa counting he new make send instance the way we normally wrap all uses of make send. On Sunday, September 19, 2010, Manuel Menal mme...@hurdfr.org wrote: On

Re: sleep in microsecond or nanosecond

Right. this is why it's tricky. You don't want to force an interrupt every microsecond just because sometimes people might be sleeping with that granularity (because it would be too often). But the delay is long enough that a busy-wait is also wrong. You need to dynamically change the clock

Re: sleep in microsecond or nanosecond

Special casing is what I had in mind, but it's very tricky. The normal wakeup-queue method is simply not adequate. On Thu, Aug 12, 2010 at 11:42 PM, olafbuddenha...@gmx.net wrote: Hi, On Wed, Aug 11, 2010 at 10:03:31AM -0700, Thomas Bushnell, BSG wrote: The current technique is to use

Re: sleep in microsecond or nanosecond

The current technique is to use a blocking mach_msg which will never complete, and with a timeout. The reason that nanosleep and usleep don't work is because 10ms is the granularity of the Mach clock. Changing the interface here isn't the issue so much as changing the implementation. Thomas On

Re: Berkeley Packet Filter

On Mon, 2009-07-06 at 21:01 +0800, Da Zheng wrote: Samuel Thibault wrote: Da Zheng, le Mon 06 Jul 2009 14:23:20 +0800, a écrit : Thomas Schwinge wrote: Zheng Da asked me to tell him about previous work that has been done on supporting and using Berkeley Packet Filters. Here

Re: Weird O_RDWR flag definition

On Fri, 2008-10-31 at 23:56 +0100, Adam Tkac wrote: if (mode O_WRONLY) die(); That was never correct code. Thomas

Re: What operations in store_parsed_open() need the privilege?

On Thu, 2008-08-28 at 08:42 +0200, Neal H. Walfield wrote: At Wed, 27 Aug 2008 15:05:59 -0700, Thomas Bushnell BSG wrote: On Wed, 2008-08-27 at 23:32 +0200, Da Zheng wrote: I know boot fails and gets EPERM when it calls store_parsed_open, but I need to know what operations inside

Re: What operations in store_parsed_open() need the privilege?

On Thu, 2008-08-28 at 23:48 +0200, Da Zheng wrote: If the non-user can access /dev/hda1, it means he can operate the hda1 device directly without the help of the file system. Is the user really allowed to do it? In Linux or other Unix, this kind of operation is forbidden, I think. It

Re: What operations in store_parsed_open() need the privilege?

On Wed, 2008-08-27 at 23:32 +0200, Da Zheng wrote: I know boot fails and gets EPERM when it calls store_parsed_open, but I need to know what operations inside store_parsed_open() fail. Otherwise, I don't know how to fix it. Boot assumes that it is run as root, and assumes that quite

Re: What operations in store_parsed_open() need the privilege?

On Thu, 2008-08-28 at 00:21 +0200, Da Zheng wrote: Thomas Bushnell BSG wrote: On Wed, 2008-08-27 at 23:32 +0200, Da Zheng wrote: I know boot fails and gets EPERM when it calls store_parsed_open, but I need to know what operations inside store_parsed_open() fail. Otherwise, I don't

Re: Some questions about libports and notification of ports

On Tue, 2008-08-26 at 13:09 +0200, Da Zheng wrote: The purpose of the translator is to help other programs get the port to the device, so I suggested if it was OK that file_name_lookup() returns the port to the device directly. antrik said it was quite confusing for him because

Re: Some questions about libports and notification of ports

On Wed, 2008-08-27 at 03:38 +0200, Da Zheng wrote: Thomas Bushnell BSG wrote: On Wed, 2008-08-27 at 01:56 +0200, Da Zheng wrote: Yes, but the point here is that *you* are opening that file and expecting something to happen. I thought you were writing the program which would *serve

Re: What operations in store_parsed_open() need the privilege?

On Wed, 2008-08-27 at 03:48 +0200, Da Zheng wrote: It sounds as if you got EPERM from store_parse_open, but proc_getprivports is not being called, so you are having trouble understanding why you got an error message at all. Yes, exactly. This will depend much on what the store

Re: Some questions about libports and notification of ports

On Mon, 2008-08-25 at 13:20 +0200, Da Zheng wrote: Yes, these ports have the receive rights. They are used for the user program, and I want to make sure they have all been destroyed before the translator exits, so the translator knows all user programs connected to it have all exited and it

Re: Some questions about libports and notification of ports

On Mon, 2008-08-25 at 19:31 +0200, Da Zheng wrote: I don't want to destroy the port. I just want to check if all ports have already been destroyed before the goaway routine is called. To check, you use the counting routines provided. The device file is created by a translator to help other

Re: Some questions about libports and notification of ports

On Sun, 2008-08-24 at 19:36 +0200, Da Zheng wrote: As I said above, I have to make sure all ports created for the user program have been destroyed before the translator exits. Are these ports that the translator has the receive rights to? If so, then when the translator exits, they will all

Re: Some questions about libports and notification of ports

On Sat, 2008-08-23 at 13:25 +0200, Da Zheng wrote: I have to make sure every ports has been destroyed so when the translator exits, it can check if there are still users. Huh? When the translator exits, all the ports are going to be destroyed anyway. OK, maybe I should make the things more

Re: Some questions about libports and notification of ports

On Sat, 2008-08-23 at 09:36 -0700, Thomas Bushnell BSG wrote: So you have two ports. When the one going to the user is destroyed, you need to tell the device not to send any more packets. And we have a way to do that: by calling device_set_filter, and clearing out the port

Re: [PATCH] libfshelp: keep stdin and stdout open

On Fri, 2008-08-22 at 01:49 +0200, [EMAIL PROTECTED] wrote: Hi, On Tue, Aug 19, 2008 at 11:29:28PM -0700, Thomas Bushnell BSG wrote: On Fri, 2008-08-01 at 21:18 +0100, Samuel Thibault wrote: I'd agree on the principle to not leave a nul port for stdin/stdout, any other opinion

Re: Some questions about libports and notification of ports

On Fri, 2008-08-22 at 02:54 +0200, zhengda wrote: When a port_info object is created by ports_create_port() and ports_get_right() hasn't been called, we have to call ports_port_deref() to destroy the port_info object. You are still organizing things wrongly, and that's what's messing you up.

Re: Some questions about libports and notification of ports

On Thu, 2008-08-21 at 11:26 +0200, zhengda wrote: In eth-filter, I define a structure struct proxy_info { /* For receiving packets from pfinet. */ struct port_info *pfinet_pi; hurd_ihash_locp_t p_pfinetpi_hashloc; /* For receiving packets from the network interface. */ struct

Re: dir_lookup, locking and EINTR

On Fri, 2008-06-06 at 00:12 +0100, Samuel Thibault wrotekfs/dir-lookup.c:478 dir-lookup.c:478 is as follows: 469 if (! error) 470 { 471 if (flags O_EXLOCK) 472 error = fshelp_acquire_lock (np-userlock, newpi-po-lock_status, 473np-lock,

Re: hurd/libdiskfs ChangeLog dir-lookup.c

On Mon, 2008-06-09 at 21:52 +, Samuel Thibault wrote: CVSROOT: /cvsroot/hurd Module name: hurd Changes by: Samuel Thibault sthibaul 08/06/09 21:52:12 Modified files: libdiskfs : ChangeLog dir-lookup.c Log message: 2008-06-06 Samuel Thibault [EMAIL

Re: [PATCH] libfshelp: keep stdin and stdout open

On Fri, 2008-08-01 at 21:18 +0100, Samuel Thibault wrote: Hello, I'd agree on the principle to not leave a nul port for stdin/stdout, any other opinion on this? I disagree. Translators don't have such ports, and making them null encourages programs to write on them, possibly expecting that

Re: Possible bug in name of command 'settrans'

On Tue, 2008-06-10 at 12:59 +0400, A.Salatov wrote: No, you correct me if I'm wrong, but when I think about 'settrans' my mind always going to compare it to 'umount' and I started to think about a reasons why 'umount' is 'umount' and not 'unmount'. The simplest reason for it, that I could

Re: procfs - Design Issue

On Tue, 2008-06-17 at 00:18 +0100, Samuel Thibault wrote: Hello, Madhusudan C.S, le Tue 17 Jun 2008 04:12:42 +0530, a écrit : 1. Is it better to free all those nodes as soon as they are displayed and create them whenever they are required? Just do that. No need to cache anything. Just

Re: Some questions about libports and notification of ports

On Wed, 2008-08-20 at 22:47 +0200, zhengda wrote: I want to get the confirmation from you about the usage of ports_get_right(), ports_destroy_right() and ports_port_deref(). When I use ports_get_right() to get the receive right of the port, I should always make a send right for the port. So

[Fwd: Gnu Hurd people in the Boston area?]

Perhaps someone can help out John? Thomas ---BeginMessage--- Hi, Thomas. I was looking for information on the current status of GNU Hurd, to see if I can find someone to give a talk about it at our Linux and Unix user group. You gave a talk on Hurd at our group back in 1996, but I see you're

Re: Thread model

On Wed, 2008-03-19 at 21:48 +0100, [EMAIL PROTECTED] wrote: Now the basic idea behind using one kernel thread to handle several user threads is that when a user thread *would* block, you don't let it block, instead you just take it away and run some other user thread. That works very

Re: Thread model

On Tue, 2008-03-18 at 10:26 +0100, [EMAIL PROTECTED] wrote: You need kernel memory for the memory maps, at least one for each user thread. No I don't. That's precisely where it is *not* equivalent. In the model I described, the state structures for the blocked requests (I prefer not to

Re: Thread model

On Tue, 2008-03-18 at 10:14 +0100, [EMAIL PROTECTED] wrote: Hi, On Mon, Mar 17, 2008 at 07:00:02PM -0400, Thomas Bushnell BSG wrote: On Sun, 2008-03-16 at 08:25 +0100, [EMAIL PROTECTED] wrote: We could move the servers one by one -- starting with the disk filesystems

Re: Thread model

On Wed, 2008-03-19 at 17:56 +0100, Neal H. Walfield wrote: At Wed, 19 Mar 2008 09:58:57 -0400, Thomas Bushnell BSG wrote: And throwing a big wrinkle into all that is that many architectures do not make it *possible* for users to handle page faults. The processor dumps a load of crap

Re: Thread model (was: Ext2 superblock fault)

On Sun, 2008-03-16 at 08:52 +0100, [EMAIL PROTECTED] wrote: Hi, On Tue, Mar 11, 2008 at 11:19:32AM +, Samuel Thibault wrote: [EMAIL PROTECTED], le Tue 11 Mar 2008 04:53:45 +0100, a écrit : [I] suggested a more adaptive approach: Keep track of the existing threads, and if none of

Re: Thread model

On Sun, 2008-03-16 at 08:25 +0100, [EMAIL PROTECTED] wrote: Hi, On Wed, Mar 12, 2008 at 03:56:47PM -0400, Thomas Bushnell BSG wrote: The clever way is to identify the particular things in the stack which must be saved, and throw the rest away, and then restart the continuation

Re: Thread model

On Tue, 2008-03-11 at 12:10 +0100, Neal H. Walfield wrote: What you are suggesting is essentially using a user-level thread package. (Compacting a thread's state in the form of a closure is a nice optimization, but the model essentially remains the same.) The main advantage to user-level

Re: Ext2 superblock fault

On Mon, 2008-03-10 at 01:19 +, Samuel Thibault wrote: This thread is syncing everything, i.e. asking a lot of writes, which triggers the creation of a lot of threads. Unfortunately the superblock was paged out, so they all block on reading it. Unfortunately, since in Debian there is a

Re: Future of ext2 support in the Hurd?

Currently the plan (approved by RMS) is to keep the Hurd libraries at GPLv2 or any later version so that they can be linked with Linux-derived code such as ext2fs stuff, and more importantly, networking stuff. The Hurd programs themselves (rather than just the libraries) will be GPLv3, though the

Re: Maintenance of the Hurd parts in glibc

On Mon, 2007-07-23 at 02:05 +0200, Thomas Schwinge wrote: Getting non-invasive (read: bug-fixing and the like) changes into the Hurd's code base is not an issue, as I can do (and actually do) all that. For getting invasive (read: interface changes and the like) changes into the Hurd we'd

Re: Defualt socket server overriding

On Wed, 2007-06-20 at 16:20 +0200, Neal H. Walfield wrote: What is a pseudo-chroot? I think what you are proposing is essentially filtering the global name space via some fancy translator. Yes, just that. When we are just interested in overriding a small parts of the environment and the

Re: Defualt socket server overriding

On Wed, 2007-06-20 at 11:11 +0800, Wei Shen wrote: Hi, On 6/20/07, Neal H. Walfield [EMAIL PROTECTED] wrote: (1) Add a set of new environment variables, e.g. PFINETSERVER for the pf_inet server and PFLOCALSERVER for the pf_local server. We

Re: GPLv3 and Hurd? (also a possible license violation)

Ok, thanks Thomas. First you list the files with the UU copyright, including advertising clause. Roland is going to ask Utah about those. Then you list some with BSG copyright, including advertising clause. We already have permission from Berkeley to remove the clause from such files. Can

Re: GPLv3 and Hurd? (also a possible license violation)

On Sat, 2007-06-16 at 14:52 -0400, Michael Casadevall wrote: The problem stems from the fact that the GPL is a project-wide license, it's not per-file (the CDDL and MPL are per file; they aren't viral licenses). Simply having it in one file binds the entire project to that license which

Re: GPLv3 and Hurd? (also a possible license violation)

On Sat, 2007-06-16 at 14:52 -0400, Michael Casadevall wrote: * Permission to use, copy, modify and distribute this software and its * documentation is hereby granted, provided that both the copyright * notice and this permission notice appear in all copies of the * software, derivative

Re: GPLv3 and Hurd? (also a possible license violation)

On Sat, 2007-06-16 at 14:52 -0400, Michael Casadevall wrote: I had emailed Thomas in regards to this because I didn't want to start a general panic over the license. Anyway, we have a few problems in any regard (I'm a Savannah Administrator, and if we have to remove the GPL later clause, then

Re: GPLv3 and Hurd? (also a possible license violation)

On Sat, 2007-06-16 at 18:49 -0400, Michael Casadevall wrote: I did cite one such case already, from cons.c (it appears in quite a few other files as well), and Thomas cited one as well. (3) all advertising * materials mentioning features or use of this software display the following *

Re: Do we want a server on `/servers/machine' (or similar)?

On Fri, 2007-05-11 at 23:45 +0200, Thomas Schwinge wrote: Hello! On Thu, May 10, 2007 at 07:32:31PM -0700, Thomas Bushnell BSG wrote: Um, well, you could keep track of the relationship, and establish the rule that a user of i386_io_perm_create sent to this special server must keep

Re: Do we want a server on `/servers/machine' (or similar)?

On Fri, 2007-05-11 at 00:06 +0200, Thomas Schwinge wrote: Now, if Roland suggests to separate the i/o port and memory access interfaces then we could (for example) simply have the suggested `/servers/ioperm' and a `/servers/mem' (or `/dev/mem'? -- but our thing is more advances than the usual

Re: Do we want a server on `/servers/machine' (or similar)?

On Fri, 2007-05-11 at 00:50 +0200, Thomas Schwinge wrote: [Remove hurd-devel.] Hello! In the server T (`/servers/ioperm') I essentially have... #v+ kern_return_t S_i386_io_perm_create (mach_port_t port, io_port_t from, io_port_t to, mach_port_t *io_perm) {

Re: Do we want a server on `/servers/machine' (or similar)?

On Wed, 2007-05-09 at 17:53 +0200, Thomas Schwinge wrote: Now, how about the following: we have a server sitting on `/servers/machine' (or somewhere else) that accepts rpcs like `io_perm_create' or `memory_map_create' and ``forwards'' (it need not really be forwarding) them to the kernel after

Re: Setting ones's priorities (was: My proposal for `PATH_MAX' and friends)

On Wed, 2007-04-11 at 12:57 +0200, Thomas Schwinge wrote: Hello! On Tue, Apr 10, 2007 at 10:10:01PM -0700, Thomas Bushnell BSG wrote: On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote: We're still being again and again annoyed by programs that use `PATH_MAX' unconditionally

Re: What is ``access (NULL, whatever)'' supposed to do?

On Tue, 2007-04-10 at 11:46 +0200, Neal H. Walfield wrote: At Mon, 9 Apr 2007 20:02:32 -0700 (PDT), Roland McGrath [EMAIL PROTECTED] wrote: It is supposed to crash. Hopefully it does not hold locks while doing so, and we should make sure that it doesn't. But anything that returns

Re: My proposal for `PATH_MAX' and friends (was: What is ``access (NULL, whatever)'' supposed to do?)

On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote: Hello! We're still being again and again annoyed by programs that use `PATH_MAX' unconditionally. Why stop with this one? Let's just drop all the Hurd features and implement the same interface as Linux, as exactly as we can make it.

Re: libtrivfs broken?

On Tue, 2007-02-20 at 00:46 +0100, Richard Braun wrote: On Mon, Feb 19, 2007 at 03:38:04PM -0800, Thomas Bushnell BSG wrote: The node doesn't belong to the user; the filesystem does not know or care what access permissions are there in the upper-level filesystem. It is in *that* filesystem

Re: libtrivfs broken?

On Tue, 2007-02-20 at 12:10 +0100, Richard Braun wrote: On Mon, Feb 19, 2007 at 05:21:29PM -0800, Thomas Bushnell BSG wrote: On Tue, 2007-02-20 at 00:46 +0100, Richard Braun wrote: I understand the point. But calling file_getcontrol() on the upper-level node won't allow us to update

Re: libtrivfs broken?

On Mon, 2007-02-19 at 23:13 +0100, Richard Braun wrote: On Mon, Feb 19, 2007 at 04:58:24PM -0500, Ben Asselstine wrote: Hello, I ran across this behaviour recently. It works if I do the same as the root user. Is anyone else having this problem? v+ [EMAIL PROTECTED]:/tmp/bing$

Re: libtrivfs broken?

On Tue, 2007-02-20 at 00:23 +0100, Richard Braun wrote: What makes you think that's a bug? I don't know if it's a bug actually, I mentionned I wanted to study the problem. Still, it seems weird that fsysopts isn't able to get the control of a node which belongs to the user. Any reason for

Re: libtrivfs broken?

On Tue, 2007-02-20 at 00:46 +0100, Richard Braun wrote: I understand the point. But calling file_getcontrol() on the upper-level node won't allow us to update the options of the trivfs translator AIUI. Isn't there a way to do that without being root ? Yes it will; it will give you the fsys

Re: An idea and proposal about system time

On Sat, 2007-02-17 at 11:06 +0100, Thomas Schwinge wrote: Looking at the source code, I see that it is used inside `pfinet' for timing issues and a few times in the file system servers. These few times are crucial; every single time a file access is performed, a timestamp needs to be marked in

Re: Copyright information

On Mon, 2007-02-05 at 21:45 +0100, Thomas Schwinge wrote: Hello! Mach files have copyright headers like this: #v+ /* * Mach Operating System * Copyright (c) 1993-1987 Carnegie Mellon University. * Copyright (c) 1993,1994 The University of Utah and * the Computer Systems Laboratory

Re: [task #5490] syslog

On Wed, 2007-01-31 at 19:13 +0200, Constantine Kousoulos wrote: typo corrections... @!#$*!! Thomas Bushnell BSG wrote: I cannot see any reason why, once the system is up and running, even proc cannot simply syslog just like anything else, provided it does not hold internal locks

Re: [task #5490] syslog

I see no reason why we should care about emulating klog. Hurd translators can, in general, perfectly well simply write directly to the regular /dev/log socket in the regular way. Heck, even the filesystem and pflocal translators can do so, since they are properly multi-threaded. The only issue

Re: notify_no_senders oddity

On Mon, 2007-01-01 at 11:49 +0100, Samuel Thibault wrote: Hi, dev = (device_t) ns-not_header.msgh_remote_port; How can this work? (I currently have a kernel fault here) A device_t and a mach_port_t are exactly the same data type, both are just integers, unless I am confused.

Re: notify_no_senders oddity

On Mon, 2007-01-01 at 20:08 +0100, Samuel Thibault wrote: Richard Braun, le Mon 01 Jan 2007 17:47:32 +0100, a écrit : On Mon, Jan 01, 2007 at 11:49:54AM +0100, Samuel Thibault wrote: Ok, and how these two views may coexist? As I showed, they _are_ mixed in the case of the linux block

Re: notify_no_senders oddity

On Mon, 2007-01-01 at 22:48 +0100, Samuel Thibault wrote: Thomas Bushnell BSG, le Mon 01 Jan 2007 12:18:17 -0800, a écrit : bd-port = ipc_port_alloc_kernel (); ipc_port_nsrequest (bd-port, 1, notify, notify); dev = (device_t) ns-not_header.msgh_remote_port

Re: notify_no_senders oddity

On Mon, 2007-01-01 at 23:05 +0100, Samuel Thibault wrote: Ok, that I can understand, but the code snippet I showed doesn't pass through MiG, it's just a function call: kern/ipc_kobject.c:ipc_kobject_notify(): ipc_port_t port = (ipc_port_t) request_header-msgh_remote_port; ...

Re: Signals, messages and exceptions

On Fri, 2006-12-01 at 15:03 -0300, Leonardo Pereira wrote: I think he isn't, Mach Exceptions are just another aproach of signals, they were used on Mach_US and Lites to implement Unix-compatible signals. The unique 'problem' is that Mach Exceptions handle not only process but also threads, so,

Re: [bug #17346] GNU mach can't handle 4GB memory

On Mon, 2006-11-20 at 16:15 +0200, Constantine Kousoulos wrote: All the above solutions aim to make Mach unaware of any memory above 1 GB. Isn't it possible to utilise all the memory? I will explain myself. I think this is clearly right, but it may well require more substantial changes to

Re: Gnumach cleanup Round 6

On Wed, 2006-11-15 at 13:43 -0500, Barry deFreese wrote: Hi folks, it's your favorite PITA again.. :-) Index: i386/i386/trap.c === RCS file: /cvsroot/hurd/gnumach/i386/i386/trap.c,v retrieving revision 1.5.2.6 diff -u -p

Re: Gnumach cleanup Round 6

On Wed, 2006-11-15 at 15:55 -0500, Barry deFreese wrote: Thomas, Thanks for the reply. Are you saying I should wrap those includes around an #ifdef MACH_KDB up where the other includes are? If so, that makes sense to me. I did not check whether the MACH_KDB check is right. But on

Re: Gnumach cleanup Round 4

On Mon, 2006-11-13 at 22:53 +0100, Samuel Thibault wrote: Roland McGrath, le Mon 13 Nov 2006 13:43:10 -0800, a écrit : Roland McGrath, le Sun 12 Nov 2006 16:50:48 -0800, a écrit : Decls for copyin et al do not belong in a machine header. Then why simple_lock_pause, spl*, for

Re: Gnumach: locore.S copyin vs. copyinmsg

On Fri, 2006-11-10 at 16:07 +0100, Samuel Thibault wrote: Hi, Barry deFreese, le Fri 10 Nov 2006 09:58:20 -0500, a écrit : From my extremely limited knowledge of assembler, copyin and copyinmsg look to be exactly the same. They are not the same

Re: Gnumach: spl.h vs machspl.h

On Fri, 2006-11-10 at 13:39 -0500, Barry deFreese wrote: Hi again folks, OK, I am confused by something else. (I know big surprise :-) ). i386/i386/spl.h #include ipl.h i386/i386/ipl.h #ifdef __ASSEMBLER__ #include i386/machspl.h ... i386/i386/machspl.h /* XXX

Re: Gnumach: spl.h vs machspl.h

i386/i386/spl.h #include ipl.h i386/i386/ipl.h #ifdef __ASSEMBLER__ #include i386/machspl.h ... You had me all confused looking at your email. What I see in i386/ipl.h is this: #ifndef ASSEMBLER #include machine/machspl.h First question is, is this an issue? machspl.h

Re: Working on stuff / statement from tschwinge (was: Gnumach clean: Need advice, re Header files)

I think Roland's email was a little over-hasty, to be sure. Let's just not fret about one message that was over-hasty and import too much to it, ok? As for the technical issue, Roland is mostly but not entirely right about what gnumach/include is for. It has both the interface files, and

Re: Working on stuff / statement from tschwinge (was: Gnumach clean: Need advice, re Header files)

As for the technical issue, Roland is mostly but not entirely right about what gnumach/include is for. It has both the interface files, and pseudo-clones of C library headers, which don't get installed because the C library has better versions. In that category are sys/types.h,

Re: Gnumach Cleanup Round 3 - Move printf.h and add panic declaration

Why the change to add parentheses to printf.c:_doprnt? (If this is to shut up a gcc warning, then it seems ok, I guess.) We do not normally put comments on #include's saying why the file was included for a couple reasons: it very quickly gets out of date, and it doesn't really communicate

Re: Stack protection via GCC's `-fstack-protector'

On Wed, 2006-11-08 at 22:40 +0100, Thomas Schwinge wrote: [Please keep both bug-hurd@gnu.org and grub-devel@gnu.org in the recipients list.] Is it feasible to have the `-fstack-protector' functionality in GNU Mach and GRUB2 (and how to do that, then) or shall we unconditionally pass

Re: Gnumach kern/strings.h

On Tue, 2006-11-07 at 10:26 +0100, Samuel Thibault wrote: Hi, Claudio Fontana, le Mon 06 Nov 2006 19:14:04 -0800, a écrit : is this to be the regular header that application developers include under your system to see all standard string functions declared? Nope, that's only for kernel

Re: Gnumach clean-up Round 2

On Tue, 2006-11-07 at 12:18 -0500, Barry deFreese wrote: Here is a patch for another round of cleanup. This gets rid of warnings for strcmp, strlen, and printf. I don't think we should have a file called stdio.h unless it's going to support all of stdio. printf.h is a much better name for a

  1   2   3   4   5   6   >