Don't worry so much. Just add an alternative to the union inside struct
device in ds_oskit.h. Having 8kb there for a whole bitmap might be a bit
much, so use a pointer to a bitmap allocated with kmalloc or zalloc.
___
Bug-hurd mailing list
[EMAIL PRO
After getting:
root@hurd:~/hurd.stuff/gnu-hurd/hurd/src/build/utils# rpctrace
/hurd/storeio
task566-> 2030 () = 0 {4096 21108 3516 3331 3639 208937 0 30188 22846
842725 43773 95312 86605}
task566-> 2029 (134217728) = 0 134512640 20480 5 7 1 0 68 0
task566-> 3206 (pn{
5})rpctrace: ../../../util
On Wed, Oct 10, 2001 at 06:46:22PM -0400, Roland McGrath wrote:
> gnumach is never going to have SMP support anyway, so it's all moot (and
> the macros you are using expand to empty). In oskit-mach, I think we
> should get rid of the lookup table and just hang the data directly off the
> device_t
From: Derek Fults <[EMAIL PROTECTED]>
Date: Fri, 12 Oct 2001 13:09:17 -0500
I am also working on trying to port Hurd to OSF mach. I need to
get a hold of a mig that generates the correct code for OSF mach,
(without typchecking). Peter Bruin said he could get me one in a
couple
> However, this assumes that shadowfs always has at least the permissions of
> the user. If for example root wants to create a directory, he can not do it
> through shadowfs if it runs as a user, he will not be able to do it through
> shadowfs, right? Not that this is a big problem, as root is a
> I think I will work on a solution for oskit-mach and forget gnumach for now.
> I have a solution for gnumach ready, but there are bugs and it is more
> difficult to debug than oskit-mach. (I have a second computer do to remote
> debugging now).
:-) You won't get any argument from me!
> In osk
Hello,
the first patch allow programs to set the serial line speed at 57600 and
115200.
diff -ur hurd-20010817/term/devio.c hurd-20010817.new/term/devio.c
--- hurd-20010817/term/devio.c Sat Mar 18 19:37:21 2000
+++ hurd-20010817.new/term/devio.c Sat Oct 6 11:50:58 2001
@@ -164,10 +164,
On Wed, Oct 10, 2001 at 06:46:22PM -0400, Roland McGrath wrote:
> gnumach is never going to have SMP support anyway, so it's all moot (and
> the macros you are using expand to empty). In oskit-mach, I think we
> should get rid of the lookup table and just hang the data directly off the
> device_t
>> and what
>> the geometry of the drive is. Also, have you tried Parted under
>> GNU/Linux? If so, what kind of results are you getting.
>
> Argh! It was horrible. Seems there is a terrible bug in the Linux code.
> Or parted is doing nasty things. It didn't crash the kernel, but the mount
> t
Figure out the sequence of device RPCs involved (rpctrace?) and work on a
test program that just does those to tickle the kernel bugs.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
On Fri, Oct 12, 2001 at 09:28:24PM +0200, Neal H Walfield wrote:
> This could be the kernel, however, I am still a bit suspicious of Parted.
You are right. It even brought down Linux.
> > I forgot if I mentioned this in my other mail: OSKit Mach doesn't
> > crash.
>
> Ah, well, then I would n
On Fri, Oct 12, 2001 at 09:03:56PM +0200, Marcus Brinkmann wrote:
> In GNU/Linux, nothing else happens (no crash, no error).
Just when I sent that, it went down.
So everyone be warned that using parted 1.5.4 is very dangerous.
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.o
On Fri, Oct 12, 2001 at 08:39:26PM +0200, Neal H Walfield wrote:
> When you say that you are running it as a normal user, does the normal
> user have access to the device or are you using a file store?
Yes, read-only.
> I am
> also interested in seeing exactly what commands you executed
check 1
>> Finally,
>> could you give a more detailed explanation of what crashing GNU Mach
>> means: are you brought to ddb, are any errors sent to the console?
>
> The error is different each time, the crash itself spurious. I am quite
> certain that random data in the kernel address space is corrupted
On Fri, Oct 12, 2001 at 08:39:26PM +0200, Neal H Walfield wrote:
> When you say that you are running it as a normal user, does the normal
> user have access to the device or are you using a file store?
Th user had read access to the device /dev/hd0.
> I am
> also interested in seeing exactly wha
> I have tried parted 1.5.4 in the Hurd running the latest GNU Mach package.
> I run "check 1" to check the first partition, which is a FAT. It really
> had a bad impact: I got completely random crashes (obviously some corruption)
> in the kernel, often during the check, but also later. This ha
It will really depend on the details of each case what I think is the best
thing to do. So for now, just do whatever is simplest and cleanest in your
mind, and when I see all the code I will figure out what I think.
___
Bug-hurd mailing list
[EMAIL PRO
Hi,
I have tried parted 1.5.4 in the Hurd running the latest GNU Mach package.
I run "check 1" to check the first partition, which is a FAT. It really
had a bad impact: I got completely random crashes (obviously some corruption)
in the kernel, often during the check, but also later. This happe
I am also working on trying to port Hurd to OSF mach. I need to get a hold
of a mig that generates the correct code for OSF mach, (without
typchecking). Peter Bruin said he could get me one in a couple days but I was
interested if knew where I could get one earlier?
Thanks
On Wednesday 1
Hi,
Before I make patches, I'm first going to clean up my code a bit, because
a lot of it consists of hacks. Would it be best to have the OSF Mach-specific
things (e.g. a device_open function which uses the GNU Mach syntax and calls
the Mach function using the OSF syntax)? Or should we just use:
I have also looked at the mips code, so it could also be based on that (I don't
have my code here, so I'm not sure). I haven't tried 'cat' yet, but C-c doesn't
work as far as I have tried, so rpc_trampoline is probably buggy.
You can get the powerpc manuals at www.mot-sps.com or www.chips.ibm.com
On Fri, Oct 12, 2001 at 05:12:12AM -0400, Roland McGrath wrote:
> I think I disagree with all of your conclusions
Only because you thought of io_restrict_auth, and we didn't :-P
I am very glad to hear that there is a solution.
> So,
> use io_restrict_auth to get a port to the writable underlyin
> there was a discussion about Shadowfs' write support on IRC (#hurd @
> openprojects.net) and Marcus suggested to post the conclusions - so
> here they are.
I think I disagree with all of your conclusions, but I'm very glad you've
been talking about the subject. (I hope this means someone wants
23 matches
Mail list logo
