Subject: Re: kernel oops when writing to hfs filesystem, + varous other problems
From: Timothy A. Seufert (tas@mindspring.com)
Date: Sun Mar 03 2002 - 15:16:22 MST
At 6:02 PM +1100 3/3/02, Ben Stanley wrote:
>Now, I still have a problem with CDRoms... How can I read an hfs+ CDROM from
>inside mol? At the moment, I have to reboot into MacOS. I tried starting
>Drive Setup on MacOS, but it won't scan the SCSI bus (mol prints something
>about an un-implemented gestalt when you try). (You can then manually mount
>any volumes that it finds.)
I don't think I ever managed to mount a CD on the fly.
>And one last problem: Is there any way that I can run mol at a custom screen
>size (ie. slightly smaller than the full screen size)? I can re-size the
>screen using the control strip, but that only gives me the choice of
>standard screen sizes.
Don't know about this one either. I assume that your desire here is
to run MOL in a X11 window while using as much of the screen as
possible? So the custom resolution would be just enough smaller that
there is space for the window manager's borders and widgets?
Actually the best MOL setup is fullscreen mode. It's a *lot* faster
that way. You can use virtual consoles to flip between MOL and X11.
>> Ideally one would make a single file system driver that knows both. As far
>> as I can tell, that's how Darwin (MacOS X) works. A lot of the stuff is
>> similar enough between the two that it's very possible to just treat HFS
>> as a subset of HFS+, or something like that.
>
>Sounds like you'd end up with a lot of if statements... sometimes it's
>better to just fork it and be done with it. Perhaps a study of the Darwin
>code is in order before deciding to do this.
The main reason I even suggested it is that the Darwin code seems to
be pretty clean despite supporting both FSes from one codebase. :)
>Funny... I had another opinion from a seasoned coder that it shouldn't be
>very hard... but, I guess that's the difference between relative newbies in
>the area and someone who's already coded a compressed audio decoder...
Heh. Everything is easier once you've got a few projects under your belt.
>Our projects work in groups of 4 or 5 students. It is just as much an
>exercise in learning to operate in a group as anything else. I would expect
>it to take them half of the year to find their feet, and a few more months
>to punch something out...
Well, given that I'd say it sounds like a cool project. A full year
and 4 or 5 sets of eyes to look at the problem gives them plenty time
to puzzle things out, and there's a *lot* of stuff to be learned in
the process even if the end result isn't a bulletproof HFS
implementation.
>Even parts of hfs need to be cleaned up / debugged / finished off. For
>example, we need an fsck for hfs. Even if the project group only did some
>of these tasks, that would be useful.
Apple has a fsck_hfs, but I don't know if it's in the Darwin source
or not. (Probably is.) If it is, it could be a very useful
reference.
Another tool that is needed is a better hformat. Right now it only
supports HFS and doesn't handle partitions larger than 2GB correctly
(the FS is created as if the partition is 2GB).
>I suppose that someone writing an fsck might find it useful to collect
>images of damaged filesystems (preferably small), so as to verify that
>the program can detect and fix the damage. And I know that there is a
>difference between Norton's Disk Tools and Apple's Disk First Aid.
>
>I presume that linux can mount .img files as a filesystem? That would be
>really useful for testing.
Yes, through the "loopback" device. Image files are just raw
block-for-block copies of the original FS, no header or anything. A
damaged FS captured with normal Macintosh utilities may have to be
stripped down to just the raw data since I think most of them have at
least some kind of a header.
For a while (early 2.4 series? memory is fuzzy) the loopback device
was kind of broken, but I *think* it's back to being stable.
>And I can see that User Mode Linux would allow
>for a real speedup in the development process, because you can then run gdb
>on the kernel, and bugs in the code under development don't jeapordise the
>stability of the underlying system. And the preemptive kernel patch makes a
>single cpu machine behave much more like smp, so that should be good for
>testing.
I wouldn't count on it exposing as many locking bugs as real SMP. :)
-- Tim Seufert
This archive was generated by hypermail 2a24 : Sun Mar 03 2002 - 15:31:37 MST