[openbeos] Re: Haiku VMware video driver in BeOS 5 PE?
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 07 Feb 2007 13:29:34 +0100
On 2007-02-07 at 00:54:37 [+0100], Simon Taylor <simontaylor1@xxxxxxxxxxxx>
wrote:
> > > Note: I think the package names are a bit odd... should we remove the
> > > "-cvs"
> > > entirely? change them all to "-svn"? - put "r5" in the filename
> > > somewhere?
> >
> > Well -cvs means -current to most users. But yeah -svn is more logical.
> > The separate zip kind of implies R5, else it would likely be in an
> > image anyway. For now.
>
> I think the names could be clearer. Last weekend I was attempting to get
> BeOS back on this computer so I could try out a new Haiku build - and
> grabbed the sis900 and nvidia zips from the factory.
>
> I'm not sure if there's a problem with them because neither worked for me
> (syslog mentioned nv trying to link with kernel.so and didn't say anything
> about sis900). I actually assumed maybe they weren't R5 builds as it didn't
> mention it in the name, and just got the bebits releases - which both
> worked fine.
I'm not sure what the build factory does, but when building the packages with
TARGET_PLATFORM "haiku" you get packages for Haiku. Having been linked
against kernel.so is a good indication that your package is indeed a Haiku
package. The build system could encode the target platform in the package
file name, but it does already place the files in respectively named
subdirectories. Doing both would be kind of redundant. The build factory
could simply rename the packages when copying them to another place, though.
> On the same sort of note, I've currently got R5 set up on my "Haiku"
> partition, so I'm trying to move it into an image file on a FAT32
> partition. It doesn't seem to work though - a 3GB D:\BEOS\image.be does not
> appear in the boot menu and is listed in Tracker's mount menu as
> /virtual/fmap0 after booting the real partition, rather than the actual
> name of the image.
I can't recall ever having heard of that feature. I've never had a FAT
partition either, though.
> Tracker gives a "does not exist" error when I click to
> mount it, although Axel's "mountimage" can mount it OK (BeOS freezes soon
> after but that always seems to happen with image files mounted from FAT32).
> Any ideas anyone?
Regarding the crash when mounting an image located on a FAT partition, that
is to be expected, since this kind of recursive image mounting isn't really
supported by the dosfs implementation. AFAIK only the BFS implementation
supports this feature, and, due to issues with the R5 block cache, reliably
only read-only.
CU, Ingo
Other related posts:
