Re: Doxygening Mach and Hurd

GNU Mach would greatly benefit from doxygen if we used it (quoting the official site) "to extract the code structure from undocumented source files. This is very useful to quickly find your way in large source distributions. You can also visualize the relations between the various elements by mean

[Fwd: Re: Putting a random translator into the Hurd directly?]

Oops, i forgot to cc the bug-hurd list. Original Message Subject: Re: Putting a random translator into the Hurd directly? Date: Tue, 12 Jun 2007 08:39:37 +0300 From: Constantine Kousoulos <[EMAIL PROTECTED]> To: Michael Casadevall <[EMAIL PROTECTED]> Referen

Re: Putting a random translator into the Hurd directly?

Michael Casadevall wrote: I've recently started hacking on Hurd again, and I'm curious why a random translator isn't included by default in the Hurd. Looking at the wiki, there are at least two different translators; we should have one of these included out of the box because without /dev/(u)ra

Re: build error : osit.version.h less than required ???

Hello Ashish, I also believe you have done something wrong. In gnumach branch-1 there is no file oskit/version.h, nor there is an entry in configure.ac refering to that file. You should delete what you have downloaded and use a command like the one Barry advised you to use to get a fresh vers

Re: Device drivers in Mach?

[EMAIL PROTECTED] wrote: Hello, Hello Leslie when I went to the task page with notes on the coming sound system, I noticed that it's written there that device drivers go into Mach. Why is that? I thought a big point of micro kernels was that a single malfunctioning driver couldn't affe

Re: [task #1618] Allowing filesystems larger than ~2 GB

From the wiki: "Note that, while the official CVS sources still suffer of this problem, recent (as of 2007) Debian GNU Hurd distributions do not have this limit anymore. Be happy." I must be missing something serious here because the following question logicaly arises. How can this problem be

Re: Google Summer of Code 2007

IMHO, o GSoC project should be something doable that can be completed within the given time. Too broad tasks should be avoided. Libchannel is a prerequisitive for many proposed projects. I think that any project that depends on it, should not be proposed. IMHO, each project should be independe

Re: looking into the amd64 arch problems

Hello again, the bug report continues: # uname -m i386-AT386 Since my notebook has a turion processor, shouldn't 'uname -m' produce something like 'x86_64'? Uname seems to be buggy even when a non-amd processor is concerned, as i have pointed out earlier (http://lists.gnu.org/archive/html/b

Re: looking into the amd64 arch problems

Samuel Thibault wrote: Constantine Kousoulos, le Mon 05 Mar 2007 20:37:25 +0200, a ιcrit : I know that the amd64 arch is a big problem. Maybe with a little help i could pinpoint some bugs and, maybe, fix them. I wouldn't say so big a problem, since Mach got to boot fine :) :) ./n

looking into the amd64 arch problems

Hello all, I tried installing Hurd on my Turion powered notebook from a Debian K14 GNU/Hurd cd and these are the results. The system boots without problems the first time! :-O The problems start after the commands #export TERM=mach #./native-install Although 'native-install' "completes" and

task #5363: `uname -m'

" `uname -m' currently reports `i686-AT386', compared to `i686' on GNU/Linux. Is there a reason to be different? " I have the same question too! :) It's easy to make 'uname' show just the machine name and not the ugly '-AT386' part. This is how i did it: diff -u hurd/proc/host.c.original hurd/p

Re: task #5130 - random translator

Kenneth Ψstby wrote: It seems like the correct way to go is to trap some sort of keyboard/network/interrupt. How is the right way to trap those ? AFAIK, the correct way to trap those things is to modify the Mach kernel. Now the next question, is there some documentation about the workings

Re: [task #5490] syslog

Thomas Bushnell BSG wrote: We generally tend to dislike the use of asynchronous messages. They are great for Mach, but we would like to avoid the need to use them in general. Keeping things always as RPCs makes the system much more likely to be portable in the future to other kernels. It's n

Re: [task #5490] syslog

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 as it does so (and this should be true for *every* call to syslog anyhow, in wh

Re: [task #5490] syslog

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 as it does so (and this should be true for *every* call to syslog anyhow, in whatever program). I can see h

Re: [task #5490] syslog

Here is my simple translator named logrelay. A first attempt to syslog the proc server could be the following: --- hurd/proc/mgt.c 2003-08-17 01:19:37.0 +0300 +++ mymgt1.c2007-01-29 21:04:45.0 +0200 @@ -18,7 +18,7 @@ the Free Software Foundation, 675 Mass A

Re: [task #5490] syslog

Hello all, In order to make the Hurd servers use syslog, i have set up a simple translator that can receive log messages and then call syslog on behalf of the sender. I have experimented with the proc "server" and it seems to be working. What do you think of this approach? Another matter is what

Re: user-mode-linux for Mach?

O/H Thomas Schwinge έγραψε: Hello! On Thu, Dec 14, 2006 at 12:36:21AM +0200, Constantine Kousoulos wrote: Currently, uml does not support device handling from user space nor has been ported to any os other than linux. However, it is just a user space process, so i'm not pessimistic

Re: user-mode-linux for Mach?

Currently, uml does not support device handling from user space nor has been ported to any os other than linux. However, it is just a user space process, so i'm not pessimistic about porting it to the Hurd. I'm clueless about system call interception and ptrace() in GNU/Hurd. Most likely, t

user-mode-linux for Mach?

Would Mach benefit from using user-mode-linux? I'm thinking that IF user-mode-linux could be ported to Mach, it MIGHT be possible to modify it in order to use some of linux's drivers in user-space. One could imagine other uses as well. Could something like this work? I know there are many seri

Re: Moving `migcom' out of `[exec_prefix]/libexec/'

Barry deFreese wrote: > Constantine, I'm speaking out of my ass as usual but I assume he suggested Ben because we would prefer using argp and Ben is the argp master. But what you have looks reasonable. Barry, this is the kind of sincerety i like in a man. Thank you for your explanation.

Re: Moving `migcom' out of `[exec_prefix]/libexec/'

Thomas Schwinge wrote: Hello! In the GNU MIG package, I'd like to move the `migcom' program out of `[exec_prefix]/libexec/' (which is where is currently is being installed) and install it alongside the `mig' program into `[exec_prefix]/bin/' for being able to use it directly, avoiding constructs

Re: [task #5490] syslog

[EMAIL PROTECTED] wrote: > Normal programs contact syslog using normal POSIX mechanisms. The low-level Hurd servers however work below the POSIX environment -- they are responsible for *implementing* these mechanisms. You need to find a way for syslog to get information from the low-level serve

Re: [task #5490] syslog

Barry deFreese wrote: Constantine, AFAIUI, the task IS to make Hurd code write entries to syslog. ITAIT, i'm on it! (ITAIT = If That's All It Takes :) ) Thanks, Constantine ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mail

[task #5490] syslog

Hello again, From http://savannah.gnu.org/task/?5490: "Find and implement a suitable way to make the Hurd servers use `syslog'. " Can someone explain what this task demands to be done? Debian's syslogd seems to be working with the current GNU/Hurd snapshot. To test it, i added a few syslog e

Re: Maintaining Tool Chain

Halil Demirezen wrote: Hello, I want to apply for the "Maintaining Tool Chain" project. How ? You already did by expressing your interest! If your help is needed, you will be informed through this mailing list. Constantine ___ Bug-hurd ma

Re: mach_msg trouble

[EMAIL PROTECTED] wrote: Hi, On Thu, Nov 23, 2006 at 09:31:27PM +0200, Constantine Kousoulos wrote: I'm trying to set up a simple server that just receives messages (not threaded). So, i have written [...] Out of curiosity: Why are you working at such a low abstraction level? You have

Re: mach_msg trouble

Richard Braun wrote: ... When threads are in different tasks, the problem is usually solved by a server dedicated to registering ports and known by all threads. The Hurd actually uses the file system for this (see the Hurd function file_name_lookup()). It's not the role of Mach to provide such a

Re: mach_msg trouble

Constantine Kousoulos wrote: ... port_err=mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &name); if (port_err!=KERN_SUCCESS) error(1, port_err, "cannot allocate port, %d", port_err); msg_err=mach_msg(&msg_body, MACH_RCV_MSG, 0, sizeof(msg_body

mach_msg trouble

I'm trying to set up a simple server that just receives messages (not threaded). So, i have written /* for port allocation */ ipc_space_t ist; kern_return_t port_err; mach_port_t name; task_t self; /* for message reception */ mach_msg_return_t msg_err; mach_msg_header_t msg_body;

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

Samuel Thibault wrote: Constantine Kousoulos, le Mon 20 Nov 2006 16:27:07 +0200, a écrit : Oops wrong copy-paste. Correct my previous email with this: ... Mach's virtual address space is 4 GB big according to this entry in gnumach/i386/i386/vm_param.h: #define LINEAR_MAX_KERNEL_AD

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

Hello, 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. Why don't we make Mach's kernel address space larger so that the whole memory can fit inside it? Mach's virtual address space is 4 GB big acc

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

In gnumach/i386/include/mach/i386/vm_param.h: /* User address spaces are 3GB each, starting at virtual and linear address 0. */ #define VM_MIN_ADDRESS ((vm_offset_t) 0) #define VM_MAX_ADDRESS ((vm_offset_t) 0xc000) In gnumach/i386/i386/vm_param.h: /* The kernel address s

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

Thomas Bushnell BSG wrote: 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 re

Re: Maintaining the tool chain

Barry deFreese wrote: Thomas Schwinge wrote: Hello! I just added an item to ``The GNU Hurd - People at Savannah: Project Help Wanted'', : #v+ ``Maintaining the tool chain'' We seek help in keeping the Hurd-specific parts of the GNU tool chain (mos

Re: Working on stuff / statement from tschwinge

Please allow me to add something. I'm relatively new to the GNU Hurd project, so i don't know a lot of things that are technical in nature or otherwise (eg Szmidt's history). However, i do know one thing. All Hurd needs to survive is a community of people that actually care for Hurd to survive.

Re: Update on glue code

Barry deFreese wrote: Does this mean you are done with the 2.6 driver code? ;-) Barry deFreese (aka bddebian) Hello Barry, My questions about pthreads came up due to something i happened to read resently. These questions have nothing to do with driver code and just fill in some blanks i have

Re: [task #5487] cthreads -> pthreads

Richard Braun wrote: On Tue, Nov 07, 2006 at 03:21:29PM +0200, Constantine Kousoulos wrote: What exactly does the term "mostly functional implementation" mean? Many things work, a few don't. That wasn't what i meant. I would like to know what are the major things th

Re: [task #5487] cthreads -> pthreads

Thomas Schwinge wrote: Follow-up Comment #1, task #5487 (project hurd): Attached is the work that Vicente Hernando Ara has been doing years ago, see . This link is obsolete. From Savannah (http://savannah.gnu.org/task/?54

Re: Drop i860 and PS2 support ?

Samuel Thibault wrote: Hi, Ok, I've done it. And this led me to the question: will anyone complain if I drop the iPSC386 support? Samuel Go ahead! Constantine ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-

Re: Drop i860 and PS2 support ?

Samuel Thibault wrote: Samuel Thibault, le Thu 02 Nov 2006 00:17:57 +0100, a écrit : The memory mapping code is a bit cluttered with i860-specific hacks, and the pic/pit/gdt/clock code is clutter with PS2-specific hacks. Maybe we should drop the support for these oldies? Put another way for m

Re: Drop i860 and PS2 support ?

From my very brief experience with GNU Mach, i came to realise that it is filled with oldies that are not needed anymore. So, whoever vollunteers to clean up some of them, is more than welcome. Constantine ___ Bug-hurd mailing list Bug-hurd@gnu.or

Re: Recent TODO list

Shakthi Kannan wrote: Hi, Where can I find the latest TODO list for GNU Hurd? Thanks, SK Hello Shakthi, You can take a look at the links below http://www.gnu.org/software/hurd/devel.html http://savannah.gnu.org/task/?func=browse&set=open&group=hurd Regards, Constantine _

Re: transition to automake'fied GNU Mach

Constantine Kousoulos wrote: After the upgrade to automake1.9 the problem persists. When i wiped my build directory and reconfigured, the problem remained the same. What was actually needed was a 'autoreconf -vfi' to get things working. After that, 'configure' and 

Re: transition to automake'fied GNU Mach

Thomas Schwinge wrote: [Back on the list.] Hello! $ automake --version automake (GNU automake) 1.4-p6 $ autoconf --version autoconf (GNU Autoconf) 2.60a The ancient version of Automake is very likely the problem. How do you happen to have such an old version of Automake installed, but

Re: transition to automake'fied GNU Mach

Thomas Schwinge wrote: However difficult the previous build system was, i have managed to compile some of the linux-2.6 kernel drivers by using it. This is great news! Did you ``only'' get them to compile or do they actually work? Currently i am at the compile-only stage. I have narrowed do

transition to automake'fied GNU Mach

Hello, First of all, many congrats to Thomas Schwinge for his effort to automake'fy GNU Mach. The old make-based code had become a serious drawback to the scalability and resusability of the system. However difficult the previous build system was, i have managed to compile some of the linux-2.6

Re: gcc errors

O/H Constantine Kousoulos έγραψε: As i have mentioned before, i'm trying to glue linux-2.6 device drivers to Mach. While i was compiling a few *umodified* linux-2.6 files,... Correction: sched.h is a modified linux-2.6 s

gcc errors

Hello, As i have mentioned before, i'm trying to glue linux-2.6 device drivers to Mach. While i was compiling a few *umodified* linux-2.6 files, i came across some errors. I'm not sure if these errors are pure compilation errors or there is something wrong with gcc on Mach. I'm inclined to believ

Re: Getting started with hurd

Hello Balaji, These are good places to look for information (i'm sure you've already found them): http://www.gnu.org/software/hurd/ http://hurd.gnufans.org/ http://www.debian.org/ports/hurd/ Looking for something to do? Here are a few ideas: http://savannah.gnu.org/task/?func=browse&set=open

Re: GNU Mach glue code update

O/H Richard Braun έγραψε: Actually, there is only one interface, the device_xxx() routines... Ok. So there are as many device_xxx() routines as the types of drivers that mach supports. How does mach choose the correct device_xxx() routine from the many available? Let's say that mach needs t

Re: GNU Mach glue code update

Hello, As it seems, mach has a "dual" device interface. Firstly, there is the native device interface (device_open, device_close etc). Secondly, there is the linux emulation device interface (again device_open, device_close, etc in seperate files) that glues linux drivers with mach. How does mac

Re: GNU Mach glue code update

I think it is clear that writing glue code is the way to go with the current gnumach driver framework. Personally, i am not biased towards porting freebsd or linux drivers. Using one or the other has its pros and cons. However, linux device drivers are better documented than than of freebsd's. I

Re: GNU Mach glue code update

Hello all, Sometime ago, i posted a question on bug-hurd: http://lists.gnu.org/archive/html/bug-hurd/2006-05/msg00040.html. At that time, I decided to work on gnumach's device drivers but i didn't announce it for a few reasons. First, i 'm no linux kernel guru, so i needed time to explore the inn

open tasks

Hello hurders, I would like to work on the GNU Mach microkernel in the direction of its improvement/stabilization. Thomas Schwinge has submitted a couple of tasks at savannah that point to the above direction. Thomas, can you give me some more info? 1)GNU Mach's IPC / VM system: You mention tha

Re: on Google's Summer of Code 2006

In order to be more clear, what i meant was that i would like to get involved with one of the ideas presented in http://www.gnu.org/software/soc-projects/ideas.html regarding the GNU Hurd. Would a "mentor" be willing to cooperate with a newbie or experience on the project is required? Best r

on Google's Summer of Code 2006

Greetings everybody, I am a complete newbie to the hurd project. I only recently installed hurd after a lot of troubleshooting. I am also a postgraduate student of computer science with a very gnu-ish philosophy. I 'm thinking of applying for Google's summer of code. Is there a problem i don