Re: HFS+ format

Re: HFS+ format

[Brad Boyer]

Actually, there is a project to develop an HFS+ filesystem module for Linux.
However, it isn't useful at the moment.  There is a small amount of code
available, but it is too much to send in an email, and I don't have a place
to host it.  If someone wants to volunteer to host this, I'll stick up a web
page or ftp site with the code and some info.  I currently do have it on a
publicly accessible site, but I don't want to flood it because it is on a
slow link to the net.  I might give the address to one or two more people
who are really interested, since there are already several of us in the
project.

Currently there is only a basic framework for the VFS interface and some of
the BTree parsing code, but it crashes frequently and can't do anything
useful.

	Brad Boyer
	flar@pants.nu


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: HFS+ format

[Olaf Hering]

On Sat, Jan 29, Brad Boyer wrote:

> Actually, there is a project to develop an HFS+ filesystem module for Linux.
> However, it isn't useful at the moment.  There is a small amount of code
> available, but it is too much to send in an email, and I don't have a place
> to host it.  If someone wants to volunteer to host this, I'll stick up a web
> page or ftp site with the code and some info.  I currently do have it on a
> publicly accessible site, but I don't want to flood it because it is on a
> slow link to the net.  I might give the address to one or two more people
> who are really interested, since there are already several of us in the
> project.

We can host it at ftp.suse.com or I can host it on my private domain.
I'm very interested in the HFS+ implementation.


Gruss Olaf

--
 $ man 1 current_release

BUGS
       Users never read manuals...

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

devel kernels 2.3.41

[ramp]

Hi everyone,

I hope I'm not the only one having problems getting a working
2.3.41 kernel. I downloaded the stock 2.3.41 from kernel.org.
This one didn't even compile. There were some problems with
pci.h. I then decided to go back to 2.3.40 and apply the
pre-patches [1..4] where 4 is the final 2.3.41. I was able
to successfully compile a 2.3.41pre3. However on boot I was
unable to use my keyboard/mouse. The boot messages seemed to
indicate that the keyboard and mouse were recognized. Any ideas
and fixes? 2.3.41pre2 also compiled successfully. On boot this
led to disk errors and I was asked to fsck. This was a total loss
since I could not type anything with the keyboard and mouse not
even recognized. I'm now back to my 2.2.14 and things seem OK.

Any suggestions/comments/ideas/patches will be most welcome.

Thanks - Ramprasad

The following table summarizes  ---

  Kernel           Compiles      Boots
 2.3.41               No
 2.3.41pre3          Yes          Yes (No keyboard/mouse)
 2.3.41pre2          Yes          no (led to fsck/ No kbd/mouse)l


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: devel kernels 2.3.41

[Martin Costabel]

The 2.3.41 final kernel is broken on most non-intel architectures (dma
code changed completely). I would think (and hope) the PPC kernel
developers are too busy fixing this right now to answer your question.

And many people, even on intel hardware, are seeing file system
corruption with 2.3.x kernels. Plus, the new USB code probably doesn't
work yet.

So for non-kernel-developers this means to be patient for a while.

ramp@oddjob.uchicago.edu wrote:
>
> Hi everyone,
>
> I hope I'm not the only one having problems getting a working
> 2.3.41 kernel. I downloaded the stock 2.3.41 from kernel.org.
> This one didn't even compile. There were some problems with
> pci.h. I then decided to go back to 2.3.40 and apply the
> pre-patches [1..4] where 4 is the final 2.3.41. I was able
> to successfully compile a 2.3.41pre3. However on boot I was
> unable to use my keyboard/mouse. The boot messages seemed to
> indicate that the keyboard and mouse were recognized. Any ideas
> and fixes? 2.3.41pre2 also compiled successfully. On boot this
> led to disk errors and I was asked to fsck. This was a total loss
> since I could not type anything with the keyboard and mouse not
> even recognized. I'm now back to my 2.2.14 and things seem OK.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: devel kernels 2.3.41

[Kevin M. Myer]

On Mon, 31 Jan 2000, Martin Costabel wrote:

>
> The 2.3.41 final kernel is broken on most non-intel architectures (dma
> code changed completely). I would think (and hope) the PPC kernel
> developers are too busy fixing this right now to answer your question.

I poked around a bit and found I could at least get around the compile
problem at the beginning with the following simple patch:

--- linux/include/asm-ppc/types.h.old   Mon Jan 31 16:07:01 2000
+++ linux/include/asm-ppc/types.h       Mon Jan 31 16:03:28 2000
@@ -41,6 +41,10 @@

 #define BITS_PER_LONG 32

+/* Dma addresses are 32-bits wide for now.  */
+
+typedef u32 dma_addr_t;
+
 #endif /* __KERNEL__ */

 #endif

In init/main.c, it included linux/pci.h, in which the struct pci_dev has a
new member "dma_mask".  This is of type dma_addr_t, which is defined for
i386 and sparc64 but no other architectures that I can tell.

That at least got me around the initial compile problem.  I'm working on
an Apple Network Server with a somewhat less than vanilla 2.3.41 so I'm
not sure if it compiles and boots fully (seeing as I've goofed up some
code for the secondary PCI bus on the ANS and it won't compile fully).

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: devel kernels 2.3.41

[Martin Costabel]

"Kevin M. Myer" wrote:
[]
> --- linux/include/asm-ppc/types.h.old   Mon Jan 31 16:07:01 2000
> +++ linux/include/asm-ppc/types.h       Mon Jan 31 16:03:28 2000
> @@ -41,6 +41,10 @@
>
>  #define BITS_PER_LONG 32
>
> +/* Dma addresses are 32-bits wide for now.  */
> +
> +typedef u32 dma_addr_t;
> +
>  #endif /* __KERNEL__ */
>
>  #endif
>
> In init/main.c, it included linux/pci.h, in which the struct pci_dev has a
> new member "dma_mask".  This is of type dma_addr_t, which is defined for
> i386 and sparc64 but no other architectures that I can tell.

Yes, this one is obvious. But if you have IDE enabled, there are later
on a whole bunch of new functions that are undefined, and I think it
must be pretty hard to write them. In drivers/block/ide-dma.c, you get
pci_map_sg, sg_dma_len, sg_dma_address, pci_unmap_sg,
pci_free_consistent, pci_alloc_consistent all undefined.

> That at least got me around the initial compile problem.  I'm working on
> an Apple Network Server with a somewhat less than vanilla 2.3.41 so I'm
> not sure if it compiles and boots fully (seeing as I've goofed up some
> code for the secondary PCI bus on the ANS and it won't compile fully).

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: devel kernels 2.3.41

[Ani Joshi]

On Mon, 31 Jan 2000, Martin Costabel wrote:
> Yes, this one is obvious. But if you have IDE enabled, there are later
> on a whole bunch of new functions that are undefined, and I think it
> must be pretty hard to write them. In drivers/block/ide-dma.c, you get
> pci_map_sg, sg_dma_len, sg_dma_address, pci_unmap_sg,
> pci_free_consistent, pci_alloc_consistent all undefined.

	these are the new  dynamic DMA mapping stuff, which sparc64
(others?) use.  i386 and us use static so we just 'fake' those functions.
they should be empty functions in <asm/pci.h>.  look at asm-i386/pci.h if
you need help.

	you will also run into problems with the new rw mutuxes, its a
mixture of rw spinlocks and semaphores.  there's a few asm functions which
need to be implemented and I have hack together a few of them.  You can
look at the sparc implementation if you wish.


ani


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: HFS+ format

[Dan Bethe]

> the best route may be to enhance hfsutils for hfs+ support. you don't have
> to worry about the complexity of multiple readers/writers that way but you
> get a useful, practical result. then jump into writing the kernel code
> after it works satisfactorily.

	So you can start with the userspace app and then port that to the kernel?  And
is it already GPL?  Cool.  Who wants to start on that?  :^)

=====
"Don't expect your own messiah; this neverworld which you desire is
only in your mind." -- http://www.dreamtheater.net/songb4.htm#IV5

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: HFS+ format

[Brad Midgley]

i'll bet there is an implementation of hfs+ in the mach layer.

mach needs to understand the filesystem well enough to load the server
from it. i ported hfsutils (yes, the userland stuff) to the mach layer's
bootstrap code back when the only way to install mklinux was with a macos
util and a tarball.  i'll bet mach has an hfs+ implementation (albeit
read-only) in its bootstrap section in darwin.

i realize you're right that the read/write implementation would be in the
bsd layer as i think about it...

the best route may be to enhance hfsutils for hfs+ support. you don't have
to worry about the complexity of multiple readers/writers that way but you
get a useful, practical result. then jump into writing the kernel code
after it works satisfactorily.

brad

> --- Brad Midgley <brad@turbolinux.com> wrote:
> > dan,
> >
> > > 	Is there any tool or technique to help port BSD source to Linux?  Perhaps
> > a
> >
> > are you sure darwin's hfs+ filesystem lies entirely in the bsd layer? (i
> > haven't looked at darwin source)

Brad
brad@turbolinux.com | http://www.turbolinux.com/~brad/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: HFS+ format

[Dan Bethe]

> I'm not sure the Linux VFS layer is much like BSD filesystem code
> anyway. With the recent changes in the 2.3 kernel series, it probably got
> more unlike BSD still. But I've never studied BSD source much :-)

	I'm glad we're still having the discussion about HFS support :)
	Is there any tool or technique to help port BSD source to Linux?  Perhaps a
technical layer or a methodology?  Would the BSD people know more about it,
since they've ported a lot of Linux drivers to BSD?
	On a license tangent, is the current revised BSD license incompatible with
GPL?  This url says that it is compatible:
http://www.gnu.org/philosophy/bsd.html.  Secondly, does Darwin use the new or
old BSD license?
	Thanks.


=====
"Don't expect your own messiah; this neverworld which you desire is
only in your mind." -- http://www.dreamtheater.net/songb4.htm#IV5

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: HFS+ format

[Dan Bethe]

> I think part of the problem is the license.  I believe everything
> incorporated in the Linux kernel, including modules, has to be under the
> GPL license, as it covers linking and (debatably) dynamic linking.  So a
> direct port wouldn't be possible, due to the incompatible licenses.  The
> code would have to be rewritten from scratch.

	That would be the case if software ported from BSD or from an Apple product,
was to be made part of the standard kernel distribution.  It is not necessary
for all kernel modules to be GPL.  For example, see the OSS commercial drivers.
 And VMware's GPL kernel modules that support their proprietary commercial
application.  :)
	So I'd say that it's cool to port it if that's very easy, then let people
include it on their own or as a LinuxPPC RPM, and then see about including it
straight into the kernel.
	IMHO!

=====
"Don't expect your own messiah; this neverworld which you desire is
only in your mind." -- http://www.dreamtheater.net/songb4.htm#IV5

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/