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: > Hello, > > Jonathan Sélea,

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 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 http://git.savannah.gnu.o

Re: Canterbury Tales Prologue

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

Re: Canterbury Tales Prologue

It's not *quite* an excerpt. On Tue, Mar 3, 2015 at 5:41 AM A. Fleckenstein 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? > > Best, > A Flecken

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 wrote: > So, mach-defpager "wires" all of its threads. What exactly does that mean? > I

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

2011/12/30 Jérémie Koenig > On Thu, Dec 29, 2011 at 1:25 AM, Samuel Thibault > 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 a lot of time just managing the

Re: GNUnet News: vfork and the signal race

s On Fri, Nov 25, 2011 at 4:09 PM, Christian Grothoff wrote: > On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote: > >> Programs which depend on the special suspend-the-parent behavior of >> vfork were always regarded as buggy... >> > > So relying on the well-documented

Re: GNUnet News: vfork and the signal race

The original BSD man page warned that the behavior should not be relied on. Thomas On Nov 25, 2011 4:10 PM, "Christian Grothoff" wrote: > On 11/25/2011 07:50 PM, Thomas Bushnell, BSG wrote: > >> Programs which depend on the special suspend-the-parent behavior of >> v

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 wrote: > Hallo! > > On Thu, 24 Nov 2011 15:59:55 -, Planet GNU > wrote: > > Many articles uniformly claim that using vfork shoul

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 wrote: > The whole point of OOL data is that it is relatively cheap to transfer huge > quantities. So I don'

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 im

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 wrote: > Jonathan Neuschäfer, le Mon 15 Aug 2011 22:10:06 +0200, a écrit : > > * ftpfs/host.c (split_server_na

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 wrote: > 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 keypress on the console

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, wrote: > Hi, > > On Tue, May 31, 2011 at 09:35:32AM +0200, Samuel Thibault wrote: > >> You just need another partition, run debootstrap in

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" 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 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 Forever. >

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

On Sun, Mar 13, 2011 at 7:25 PM, Samuel Thibault wrote: > 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 rendez-vous por

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" wrote: > Hello, > > I've investigated a duplicate port destroy in ext2fs, what apparently > happens is this: > > - diskfs_S_dir_lookup is calle

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" wrote: > URL: > > > Summary: GNU/Hurd headers don't pass c++ > Project: The GNU Hurd > Submitted by: sthibaul > Submitted on: di

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 wrote: > Hi, > > just looking at a recent build failure in Debian, "rdfind". > There's some code l

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 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 result of re

Re: ED error code

Agreed. On Tue, Nov 2, 2010 at 7:52 AM, Michael Banck 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 and an

Re: ED error code

On Sun, Oct 31, 2010 at 7:49 AM, Pino Toscano wrote: > > 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 it's likely that we

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 wrote: > On 27/07/2010 17:39, Emilio P

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 behavi

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, wrote: > Hi, > > On Wed, Aug 11, 2010 at 10:03:31AM -0700, Thomas Bushnell, BSG wrote: > > > The current technique is to

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 M

Re: RPC user stub libraries (was: error compiling hurd after gnumach interface change)

> * What's the reason for having a libmachuser / libhurduser be part of >glibc? > >Is it for Roland's convenience, or is there a technical reason? Can >we move it out of the glibc build process? > Given the need for the libraries, they have to be built somewhere. Since glibc needs t

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 Packe

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 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 dep

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

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 st

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 thorou

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 st

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.

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

On Wed, 2008-08-27 at 01:57 +0200, Da Zheng wrote: > I'm trying to make subhurd work without root's permission, so the first > task for me is to find the operations need the privilege. That's a worthy task. > I have a problem in store_parsed_open(). > I believe store_parse_open() calls dev_open(

Re: Some questions about libports and notification of ports

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* that file. > > > I know it's a bit confusing. Then what should I do? If you w

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 file_name_

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 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

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 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 p

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 mor

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: [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 f

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. */ >

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.

Re: dir_lookup, locking and EINTR

On Thu, 2008-08-21 at 00:39 +0100, Samuel Thibault wrote: > That's safer indeed. To make things simpler, the patch below just > systematically resets NEWPI and NEWPO to NULL as soon as they don't need > to be dereferenced, does it look ok? It does, but "NULL" is entirely unnecessary. I much pref

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 anythi

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 i

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 th

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 08/06/09 21:52:12 > > Modified files: > libdiskfs : ChangeLog dir-lookup.c > > Log message: > 2008-06-06 Samuel Thibault <[EMAIL P

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, > 473

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

Perhaps someone can help out John? Thomas --- Begin Message --- 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 ve

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 &

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 w

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 prefe

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 aw

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

Re: Thread model

On Wed, 2008-03-12 at 20:46 +0100, Neal H. Walfield wrote: > At Wed, 12 Mar 2008 15:32:26 -0400, > Thomas Bushnell BSG wrote: > > On Tue, 2008-03-11 at 12:10 +0100, Neal H. Walfield wrote: > > > What you are suggesting is essentially using a user-level thread > >

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

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 th

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 an

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. > >

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 some

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 > followin

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, th

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, derivati

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: 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 thi

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_p

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 usu

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 af

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 b

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 i

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 retu

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

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 > >

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 h

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

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]

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

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 La

Re: [task #5490] syslog

On Thu, 2007-02-01 at 00:22 +0200, Constantine Kousoulos wrote: > > It's nice to know the direction the implementation is headed. I > would be grateful if you could supply links that further document > the above mentioned statement. To be honest, i had the exactly > opposite idea since it has b

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 d

Re: [task #5490] syslog

On Wed, 2007-01-31 at 00:03 +0100, [EMAIL PROTECTED] wrote: > An interesting idea, though it doesn't really help with the problem at > hand: This thread (and I think the task it refers to) isn't about > logging from normal translators (which wouldn't need any special > facility to use syslog() in t

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 t

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: 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, ¬ify); > &g

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 b

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 Sun, 2006-12-31 at 12:30 +0100, Samuel Thibault wrote: > Hi, > > There's something I don't understand in > i386/i386at/i386at_ds_routines.c:ds_notify() > > dev = (device_t) ns->not_header.msgh_remote_port; > > How a port can be a device_t? A device_t is just a mach_port_t that is expec

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,

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 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. B

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 -

  1   2   3   4   5   6   7   >