Re: forwarded proposal to finance some hurd work

On 04/05/2011 12:14 AM, Thomas Schwinge wrote: > Marcus, is the g10 Code Hurd Maintenance Point offering still > appropriate? That one is stale. Maybe something could be arranged if there is interest. > Hurd developers, please talk to me or add yourself to that page if you > f

Re: What happens to mappings when closing file?

al client's mapping when the client closes the > file? Closing a file does not remove the mappings. From glibc manual on mmap: "A new reference for the file specified by FILEDES is created, which is not removed by closing the file. Thanks, Marcus

Re: About merging the Hurd homepage and the Hurd wiki

free software. VirtualBox may be a better replacement for vmware than qemu, and there is a functional free version of it. I wouldn't worry about scientific papers. Thanks, Marcus

Re: About merging the Hurd homepage and the Hurd wiki

by now. I don't know how translations are handled today. This is something one might want to check. I have not checked the policy in a long time. There may be some concerns about external links (no linking to non-free software etc). Thanks, Marcus

Re: e2os

e forgets to assign ownership of FS > > to hurd? If so ow it should be done and from where? > > I never used that utility. If you dare you could try to use it and > report back. It's safe, it just sets a bit somewhere. Marcus

Re: Thread model

threading model, more than one kernel thread per real CPU doesn't seem to make much sense in most cases. Thanks, Marcus > An orthogonal concern is the use of locks. An approach to reducing > their number is the use of lock-free data structures. See Valois' > thesis for a st

Re: User-space device drivers: ``interface to interrupt hardware'' (was: writing device drivers in Java)

r and M. Hohmuth. > > Can any of the L4-savvy people (Marcus?, Neal?) comment on this? Is this > feasible for Mach as well? Is this what L4 is still using? I can see > code for this in the TU Dresden L4 repository, so i guess they're > actually actively using this proposed

Re: Entropy Patch with Linebreaks

on of the methods used to measure entropy. It's a good idea to be conservative about entropy measurements. Commonly it is overestimated by a large margin. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Future of ext2 support in the Hurd?

ition, your position (and Remy Cards', Linus Torvalds' etc) matters as well, of course. As a side not, personally I am confident that most of these cases can be resolved quickly and amicably, and will have exactly the outcome that common sense suggests. The other cases I will happily lea

Re: Future of ext2 support in the Hurd?

pport for it. In fact, we are very happy with it. How much are we a burden for you? If it helps, we can probably arrange it so that a volunteer cooperates with you if work is involved in keeping the support active. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: [task #7179] Multiprocessor support

t" need testing. What about the device drivers (glue code?). Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Maintenance of the Hurd parts in glibc (was: about GNU Hurd)

th you that using this as a backend for any of the major DVCS is a good compromise. It would be a good idea to have SVN running on the Hurd before switching. Also, I checked out savannah and could not find the option you mention above. Thanks, Marcus _

Re: Yet another updated entropy patch

At Fri, 20 Jul 2007 18:53:05 +0200, Thomas Schwinge <[EMAIL PROTECTED]> wrote: > On Thu, Jul 19, 2007 at 01:52:39AM +0200, Marcus Brinkmann wrote: > > At Thu, 19 Jul 2007 01:40:12 +0200, > > Thomas Schwinge <[EMAIL PROTECTED]> wrote: > > > What do you perceive

Re: Yet another updated entropy patch

At Thu, 19 Jul 2007 01:40:12 +0200, Thomas Schwinge <[EMAIL PROTECTED]> wrote: > Uhm, Marcus, I don't really feel like discussing such nuisance, but I'd > say that as soon as you're putting in new-line breaks (which the GCS and > our own sanity mandates) you'r

Re: Yet another updated entropy patch

At Fri, 13 Jul 2007 22:50:00 -0400, Michael Casadevall <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > (this is a response to both emails about said patch) > > Marcus: I don't think I've ever been nitpicked that badly in my

Re: Doxygening Mach and Hurd

ut of course the problem is not the markup, but in writing good documentation. Documenting the internals is important, but well written source code together with an overview manual should be more satisfying, IMO. Thanks, Marcus ___ Bug-hurd mailing list Bug-

Re: Yet another updated entropy patch

it is not a good idea to drop entropy when the pool is full (you can't increase the entropy above the pool size, but you can improve the quality of the pool by mixing more entropy into it as a safety net, even when it is full). Entropy is a scarce resource, and we have such poor entropy sources that pushing all data over to user space may be a performance issue in the current implementation (consider that all network traffic needs to be copied several times!). It seems to make sense to me to mix in the kernel, and again in user space (user space then implements pools with different qualities, based on the high quality kernel entropy pool data). Do you add timer randomness? Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Problem with login

he real console) If you don't like the login shell, you can use /bin/login-pr instead of /bin/login with getty. The pr is short for "prompt", if I recall correctly. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: fatfs: slot_status COMPRESS

gt; intend to do with the COMPRESS status (is it for vfat LFN?). See above, and yes, it is for LFN support. > I suppose the fatnamematch() will be also multiplexed with a vfatnamematch > or whatever you want to call it. I wouldn't take thi

Re: Putting a random translator into the Hurd directly?

e linux device drivers, and then use the callbacks that already are in the drivers, as they contain an entropy estimate as well if I recall correctly. This is not rocket science. It's a fairly easy step, and once that GNU Mach device exists, it makes a whole l

Re: [task #6990] Avoid copying source files from other projects

is is also done). Yes, this hides bugs, but it avoids a build time dependency and is more robust/secure (in fact, exec itself is statically linked anyway). I am not saying linking against external libz should never be done, but in the case of exec I think the argumen

Re: Write a VFAT translator

ve any suggestion or whatever you have > to say that could be help me? Good luck! :) It's not a problem to ask many questions. The more specific the questions are, the better. As an example, the three questions above were excellent questions, and a pleasure to answer. Thanks, Marcus

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

t. > > Legacy compatibility has always ruled the day. As I understood it, > the idea was to write an OS, not a distribution. That's not completely true. The goal of the GNU project is to write a complete system. Of course, our task within that is only a small part. Thanks, M

Re: rpctrace improvement for the Google Summer of Code

by rpctrace itself indirectly would likely be hazardous. Irregardless of that, being able to attach and remove a monitor to a process at runtime is certainly useful. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: typos in gnumach manual

At Sun, 21 Jan 2007 15:24:09 +0100, Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > Hello there, > > here's a bunch of typo fixes for the gnumach manual. > (You didn't mean "netword", right?) Thanks for these fixes. I put

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

st pointing at fundamental rights and doing what we want without considering the needs and wants of everybody else. Thanks, Marcus ___ Hurd-devel-readers mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/hurd-devel-readers

Re: subhurds

un by a non-privileged user, but there were some scary details that I forgot. I always used to run them as root, so I didn't test that part. Ideologically and technically, it should work. But bugs and other subtleties may prevent it from working. Thanks, Marcus

[task #5692] Data Export #5 (bugs)

Update of task #5692 (project hurd): status_id: => Closed ___ Follow-up Comment #0: [100] Job removed per request of his owner, Marcus Brinkmann 5.xml is no longer availa

[task #5692] Data Export #5 (bugs)

URL: <http://savannah.gnu.org/task/?func=detailitem&item_id=5692> Summary: Data Export #5 (bugs) Project: The GNU Hurd Submitted by: marcus Submitted on: Friday 06/30/2006 at 03:59 Category: None Shoul

Re: Linus replies. Re: Computer: Can We Make Operating Systems Reliable and Secure?

st kernel with a war on the best memory-safe programming language... Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Mach or L4 or Coyotos or ... !

ecide to contribute to the existing code base or not at all. Those people who are more adventurous and don't mind spending time on mistakes as well as successes are also invited to help with the research, of course. I am sure some old chinese guy could say all this in one fortune cookie. :) Th

[patch #4984] Remove NORMA interface from hurd code

Follow-up Comment #2, patch #4984 (project hurd): The Makeconf change can go in. The subsystems ids should stay reserved in the list. ___ Reply to this item at: __

Alfred M. Szmidt

list management issues had to be resolved. Alfred will be welcomed back when he can demonstrate that he intends to work on the project by cooperation rather than confrontation. Thanks, Marcus = Message-Id: <[EMAIL PROTECTED]> This is applied for the first patch too? It only applies to per

Re: [patch] Fix Hurd's kill(pgid, sig)

osen, it will be a startup_* interface, and that means that it can only be used by root, which is good. With your version, any process can register itself as essential, which is not so good. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: libdiskfs: build system inconsistencies; the Hurd `collecting box'

> into small packages--libpager, libdiskfs, libstore, libihash, ..., > ext2fs, ...--that _only_ use the system-wide header files (many packages; > how to combine them reasonably). The Hurd build tree should use the build-local header files when available. Thanks, Marcus

Re: Warnings removed from linux/dev/drivers/block/genhd.c

oncern. The patch contains a gratuitous change which is not explained. This is sufficient reason for us to not consider the patch. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Warnings removed from linux/dev/drivers/block/genhd.c

On Tue, 2006-01-31 at 09:11 -0200, Matheus Morais wrote: > On 1/30/06, Marcus Brinkmann <[EMAIL PROTECTED]> > wrote: > > The patch contains a gratuitous change which > is not explained. This is sufficient reason for us to not > cons

Re: config.{guess,sub}

On Thu, 2006-01-26 at 12:43 -0500, Thomas Schwinge wrote: > Hi! > > I updated config.guess and config.sub for gnumach-1-branch, hurd-HEAD and > mig-HEAD. ftp://ftp.gnu.org/gnu/config/README> I don't object, but I would like to hear your motivation for t

Re: Small console fixup

On Mon, 2006-01-23 at 20:41 +0100, Samuel Thibault wrote: > Hi, > > Here is an (I guess) obvious fixup: Doesn't save you from writing a changelog entry, though :) I checked this in. Thanks! Marcus > --- console/console-orig.c2006-01-23 20:39:56.0 +0100 > +++ co

Re: non-ascii characters and 8-bit Hurd console

gt; * input.c (input_create): Fix arguments order of iconv_open() > call. I checked this in, thank you! Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: strict aliasing problem in GNU Mach

priority, and for the original Linux source files this option is actually a necessity. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: gnumach and gcc 4.0 (patch 1)

hange or bugfix or whatever), you are welcome to send a note to the list as well ;) When I put in a patch that has been submitted by somebody else, I always send a notification to that person in reply to his submission (and to the list, if the patch was sent to the list). Thanks, Marcus

Re: gnumach and gcc 4.0 (patch 1)

As a matter of routine, personally I would go and check if the files that are taken from third parties are actually original copies of the versions as stated in the ChangeLog. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Patch submission and discussion guidelines

On Sun, 2006-01-15 at 14:20 -0800, Thomas Bushnell BSG wrote: > Thomas, if you are willing, please say so, and then we'll declare this > official. Marcus and Roland have already agreed this is sensible, so > there was no reason for delay except that my workload caused it to get &g

Re: Patch submission and discussion guidelines

bove rules. > > Yeah, I'm pissed. We encourage people to help in any way they can, and if they want to work within the Savannah tools, then they are welcome to do so. If they prefer to work via e-mail, that is also good. Marcus ___ Bug-hu

Re: Tasks list for GNU Mach

At Thu, 22 Dec 2005 13:45:05 +0100, <[EMAIL PROTECTED]> wrote: > A couple of years ago, Marcus (and some others), more and more exposed > to the problems in Mach, made the claim that Hurd/Mach has no future, > and further developement should be directed to a port to a modern > m

Re: Mach lack for frequent operations

org/publications/1996/towards-ukernels.pdf}, url = {http://www.l4ka.org/publications/1996/towards-ukernels.ps}, citeseer-url = {http://citeseer.ist.psu.edu/liedtke96toward.html} } Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: The Hurd: what is it?

At Wed, 09 Nov 2005 21:54:52 +0100, Marco Gerards wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > The active translator problem seems serious to me. Without any > > guarantee about the implementation of a service, you can not know what > > it d

Re: ams-before-putsch

At Thu, 10 Nov 2005 15:17:40 +0100, Alfred M Szmidt wrote: > >> Marcus, can you find a name for the tag which is less >> provocative? > >Well, in fact, we can remove it, because the source tree doesn't >change much these days, and thus using dates to

Re: ams-before-putsch

At Wed, 09 Nov 2005 19:58:40 -0800, Thomas Bushnell BSG wrote: > > "Alfred M\. Szmidt" <[EMAIL PROTECTED]> writes: > > > Marcus, I'm not even sure how to talk to you. Just remove that > > idiotic tag at once (unless I did it right). You have no busine

Re: The Hurd: what is it?

At Wed, 09 Nov 2005 23:22:33 +0100, Sergio Lopez <[EMAIL PROTECTED]> wrote: > > El mié, 09-11-2005 a las 20:32 +0100, Marcus Brinkmann escribió: > > We don't know (since the papers are not so technical, and we can't look > into the code) in deep what they do to M

Re: The Hurd: what is it?

At Wed, 09 Nov 2005 13:45:01 -0800, Thomas Bushnell BSG wrote: > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > This is why in FUSE, users don't see the user filesystems of other > > users. I am afraid that given the seriousness of the problem, this is > > th

Re: The Hurd: what is it?

that? In L4, a thread will donate its current timeslice to the receiving thread at IPC. But at the next preemption the server thread will only be scheduled if, well, it is scheduled. Not when the client thread is scheduled. There is no priority inheritance for the whole operation, AFAIK. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: The Hurd: what is it?

At Wed, 09 Nov 2005 09:44:18 -0800, Thomas Bushnell BSG wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > For problems with the Hurd passive translator design: > > > > http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00081.html > > I woul

Re: The Hurd: what is it?

At Wed, 9 Nov 2005 17:02:45 +0100, Bas Wijnen <[EMAIL PROTECTED]> wrote: > > Marcus made a promise to Jeff Bailey that the Hurd on L4 would be runnable > > last year. > > Marcus told you this day that he doesn't like it if you are claiming that he > said things,

Re: The Hurd: what is it?

ussion. There is no magic spoon that allows me to feed this material to a king ;) Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: The Hurd: what is it?

At Wed, 09 Nov 2005 03:27:56 +0100, Alfred M Szmidt wrote: > > Marcus, your reply is a kneejerk reaction (I base this on your > inablity to understand the meaning of `seems to be dead'). You > yourself claimed that Hurd/FOO (FOO != Mach) would require a rewrite, > and the

Re: The Hurd: what is it?

At Wed, 09 Nov 2005 04:45:32 +0100, Sergio Lopez <[EMAIL PROTECTED]> wrote: > > El mié, 09-11-2005 a las 02:00 +0100, Marcus Brinkmann escribió: > > Of course, I don't speak for Roland or Thomas. But as far as I know, > > the direction of the Hurd has not ch

Re: The Hurd: what is it?

ime be > spent on the currently working Hurd/Mach, should it be spent on the > non-existant Hurd/L4, or should it be spent on the > Hurd/something-that-doesn't-even-exist-yet? > > Marcus answer was `that is up to each and one to decide'. This is > completely inappropriate

Re: [EMAIL PROTECTED]: Re: spam]

ou added in the moderator email address field? Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Making the hurd console accessible to blind users

At Wed, 13 Jul 2005 10:07:30 +0200, Samuel Thibault <[EMAIL PROTECTED]> wrote: > > Marcus Brinkmann, le Wed 13 Jul 2005 02:09:33 +0200, a écrit : > > At Wed, 13 Jul 2005 01:03:07 +0200, > > Samuel Thibault <[EMAIL PROTECTED]> wrote: > > > It seems all

Re: Making the hurd console accessible to blind users

At Wed, 13 Jul 2005 01:03:07 +0200, Samuel Thibault <[EMAIL PROTECTED]> wrote: > It seems all ok, except that in my latest patch, the repeater_node > variable of current-vcs.c has a default value of DEFAULT_REPEATER_NODE, > because else it would segfault if one loads the driver without > specifying

[patch #2507] Patch to update autoconf files

Update of patch #2507 (project hurd): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #9: Applied an only very

[patch #4129] initialize upi->max_prot

Update of patch #4129 (project hurd): Status:None => Done Open/Closed:Open => Closed ___ Follow-up Comment #1: This really seems to

[PATCH] upgrade autoconf of GNU Mach

Hi Roland, this patch by Neal and Guillem updates the autoconf framework for GNU Mach. Thomas Schwinge tested the full bootstrap procedure; in fact he wrote a script doing the full bootstrap, which he showed to me. He also was so kind to verify (automatically) that the set of driver options didn

Re: [PATCH v2] system V shared memory support for the Hurd in glibc

there, but I expect it should. I should add that the core functionality of this patch was tested by Gael at the LSM, and mplayer works! (Of course without sound, and with dropped frames at disk I/O, but you should have seen it without shm :) Thanks, Marcus 2005-07-11 Marcus Brinkmann <[EMAIL P

Re: [PATCH] system V shared memory support for the Hurd in glibc

At Tue, 12 Jul 2005 00:20:05 +0200, Marcus [EMAIL PROTECTED] de wrote: > > Below is a temporary patch for ext2fs to support the bit used for > nattch. Only few programs will require this, though. groan. 2005-03-09 Marcus Brinkmann <[EMAIL PROTECTED]> * p

Re: [PATCH] system V shared memory support for the Hurd in glibc

At Mon, 11 Jul 2005 23:52:35 +0200, Marcus [EMAIL PROTECTED] de wrote: > this patch is for glibc, but it needs to get more testing before it > can go in. Please give it a good beating. Here is a resent in a more sane format. I have no idea why it didn't do this the first time ar

Re: [PATCH] system V shared memory support for the Hurd in glibc

At Mon, 11 Jul 2005 23:52:35 +0200, Marcus [EMAIL PROTECTED] de wrote: > > Hi, > > this patch is for glibc, but it needs to get more testing before it > can go in. Please give it a good beating. I should add some information on how to test this. The shm node is /dev/shm. Nor

[PATCH] system V shared memory support for the Hurd in glibc

ation). Getting the cuid/cgid (always just uid/gid). Verifying the cuid/cgid when accessing. Compatibility note: Most programs should work. POSIX says RMID removes all mappings, but no system does it that way (and neither do we). 2005-07-11 Marcus Brinkmann <[EMAIL PROTECTED]> * s

Re: Making the hurd console accessible to blind users

e: I renamed "vcs-repeat" to "current-vcs". We use the repeater infrastructure, but I don't really think that term is helpful here. The rest went in unmodified. I hope I didn't introduce a typo or so, and checked it in. Thanks, Marcus > Changelog for console-client/

[patch #4129] initialize upi->max_prot

URL: <http://savannah.gnu.org/patch/?func=detailitem&item_id=4129> Summary: initialize upi->max_prot Project: The GNU Hurd Submitted by: marcus Submitted on: Sun 06/26/05 at 23:42 Category: Ex

Re: [PATCH] proxy memory object

lly? 2. Apply my new patch, with the generic interface. 3. Somebody commits _now_ to implement the generic case within a reasonably short time frame. I won't do it. This is, for me, all about fixing a glaring security hole, which has existed ever since. Well, since some time it is also abou

[PATCH] proxy memory object

e real memory objects for the write object. That would be a small optimization. Thanks, Marcus 2005-06-06 Marcus Brinkmann <[EMAIL PROTECTED]> * include/mach/mach4.defs: Add memory_object_create_proxy interface. * Makefile.in (vm-cfiles): Add memory_object_proxy

Re: autoconf update patches

t; The worst case scenario that will happen is that we won't be able to > bootstrap, and if that actually would happen then we have two choices, > revert or fix; both which are trivial. So fix it now, before having the patches applied, if it doesn

Re: random translator

hardware (timing IRQ events, etc. It's not perfect, but the best thing you can get from standard PC hardware). Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

[bugs #12434] Unix-domain (local) sockets do not support getsockname() or getpeername()

Update of bugs #12434 (project hurd): Originator Name: => [EMAIL PROTECTED] ___ Follow-up Comment #1: Calling getsockname() on a Unix Domain Socket does not seem to be widely supported. I found t

[bugs #12434] Unix-domain (local) sockets do not support getsockname() or getpeername()

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=12434> Summary: Unix-domain (local) sockets do not support getsockname() or getpeername() Project: The GNU Hurd Submitted by: marcus Submitted on: Wed 03/23/0

Re: untrusted translators

than what I proposed in my last mail. For example, if you set up an active filesystem, it will inherit your "friend list", and pass it on to suid binaries started from that filesystem. Sounds fine to me. Thanks, Marcus [1] Such a solution would have the problem that if you mess up yo

Re: untrusted translators

At 20 Mar 2005 20:15:03 -0800, Thomas Bushnell BSG wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > Following untrusted translators in the filesystem is a real security > > hazard. > > Can you say more about a specific losing scenario? I did

Re: heads up

s pushed into the user space, and outside the system code. Well, there are always some drawbacks. At least in some instances we have to raise the barrier for user's sharing resources accidentially. For example, I am strictly against following translator

Re: Patch to retrieve send rights for shared memory objects

needs more testing, as reportedly it is "broken"). But it's a real showstopper for using tmpfs. Until we have worked something out, ext2fs could be used with a ramdisk though (with the usual problem that a ramdisk needs initialization). Thanks, Marcus __

Re: glibc; introducing slashpackage-foreign

also know the advantages of having all packages > > folded into a single directory hierarchy. > > I'll continue discussing that topic on gnu-system-dicuss, ok? That's up to you. ;) Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Patch to retrieve send rights for shared memory objects

f this flag all the time, we don't even need to call into Mach to find out anything for io_stat(). Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: glibc; introducing slashpackage-foreign (was: GNU Mach panic)

have the translator concept which allows for much better solutions. That's the story we gave for years now, and you can find more details about this approach in the mailing list archive. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: Patch to retrieve send rights for shared memory objects

choosing an arbitrary high value would be the most compatible (but not TYPE_MAX, because that could trigger overflow bugs). I kinda like "42". Someone at the conference (I think it was Olaf) pointed out that the actual number of bits required for three states is ln 3 / ln 2 == 1.585, not one-and-a-half. I didn't want to leave this unmentioned ;) Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: patch to enable --help in /hurd/init

Hi, Looks good to me. I have committed it, but I put the comment before the calculation of flags. I also added a small comment about the issue into the code. Thanks, Marcus At Wed, 23 Feb 2005 17:48:29 -0500, Ben Asselstine <[EMAIL PROTECTED]> wrote: > > * init.c (main

Re: isofs booting from grub

At Wed, 23 Feb 2005 00:23:53 +0100, Alfred M Szmidt wrote: > > The following is needed so that one can boot of a CD, many thanks to > Marcus. > > Ok to commit? Yes. > isofs/ChangeLog > 2005-02-23 Alfred M. Szmidt <[EMAIL PROTECTED]> > > * Makefi

System V Shared Memory File-Based Interface

Hi, > At Wed, 9 Feb 2005 13:03:17 -0500, > Barry deFreese wrote: > > Roland, marcus, etc, can someone comment on the following patch neal made > > two years ago for sysv shared memory? > > > > http://lists.gnu.org/archive/html/bug-hurd/2002-04/msg00288.html Here is

Re: Updated patch for weak aliases for glibc

Linux version of glibc. The remaining differences where in Hurd and Linux specific interfaces respectively as far as I can tell. You can check it out yourself if you want. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.g

Re: glibc changes

At Wed, 9 Feb 2005 13:03:17 -0500, Barry deFreese wrote: > I'm looking to try to do some updates to glibc. This started as the missing > weak_aliases but if possible may grow into the sysv and POSIX semaphore > stuff also. > > Roland, marcus, etc, can someone comment on

Re: SIOCGIFHWADDR support for pfinet

second question, although the answer should be readily available by looking at Linux and net-tools source code. Once we have determined that unconditionally copying the dev_addr field is ok, or did an appropriate check, it can go in (with the addr_len change mentioned above). Thanks, Marcu

Re: trivfs and port leaks

eaning > up the cntl first? No. When a task is destroyed, all ports are destroyed and all references to outside ports are released. This is handled in Mach (similar to file descriptors in Unix). Thanks, Marcus ___ Bug-hurd mailing list Bug-hur

Re: fakeroot

case would be useful (even better a small testcase which triggers the bug more often). But until then the only info we have is that fakeroot breaks under heavy load. More debugging is required. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: hurd installation

re rare enough that if that happens, you're _most > probably_ doing something wrong. This is true, but we don't want it to be that way forever, do we? :) Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: potential nanosleep() fix

At Sun, 30 Jan 2005 23:20:06 +0100, Macrus Brinkmann wrote: > 2005-01-30 Marcus Brinkmann <[EMAIL PROTECTED]> > > * sysdeps/mach/nanosleep.c (__nanosleep): Calculate remaining > time, not elapsed time. Now that was a messed up patch. Here is a new version of the

potential nanosleep() fix

, Marcus 2005-01-30 Marcus Brinkmann <[EMAIL PROTECTED]> * sysdeps/mach/nanosleep.c (__nanosleep): Calculate remaining time, not elapsed time. --- nanosleep.c.org 2005-01-30 23:12:05.0 +0100 +++ nanosleep.c 2005-01-30 23:12:43.0 +0100 @@ -44,8

Re: GNU Mach autoconf update patch [repost]

or less as described in INSTALL-cross or Alfred's Cross-compiling guide from last september. If you can't configure and run make install-headers with a broken gcc, you are in some trouble getting the system up and running. Thanks, Marcus _

Re: GNU Mach and gcc 3.4 [repost]

Applied, thanks! Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd

Re: console translator set without encoding

At 21 Jan 2005 19:31:13 -0800, Thomas Bushnell BSG wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > UTF-8 is an insanely complex standard, if you start to look down its > > depths. > > UTF-8 is a complex standard. It is not insanely s

  1   2   3   4   5   6   7   8   9   10   >