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/