| To: | Ken McDonell <kenmcd@xxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: XFS architecture ? |
| From: | "Andi Kleen" <ak@xxxxxxx> |
| Date: | Mon, 3 Apr 2000 23:58:42 +0200 |
| Cc: | Stefan Smietanowski <stefan@xxxxxxxxx>, Linux XFS mailinglist <linux-xfs@xxxxxxxxxxx> |
| In-reply-to: | <Pine.SGI.4.10.10004040735500.3397-100000@xxxxxxxxxxxxxxxxxxxxxxxx>; from kenmcd@xxxxxxxxxxxxxxxxx on Tue, Apr 04, 2000 at 07:45:23AM +1000 |
| References: | <38E8F90B.44E33FEE@xxxxxxxxx> <Pine.SGI.4.10.10004040735500.3397-100000@xxxxxxxxxxxxxxxxxxxxxxxx> |
| Sender: | owner-linux-xfs@xxxxxxxxxxx |
On Tue, Apr 04, 2000 at 07:45:23AM +1000, Ken McDonell wrote: > (b) will the Linux version of XFS support both a little endian on-disk > format (what you see today with the released code on Intel > platforms), _and_ the IRIX MIPS on-disk format Switching endians is very cheap on modern CPUs (ppro+ have a special instruction, ultrasparc/ia64/et.al. have special bits in the store instructions to store both endians). What is expensive is checking whether you need to switch (or rather, it is not that expensive at runtime, but bloats the code/binary a lot because a lot of routines will be duplicated) Big-Endian XFS everywhere probably makes sense. TCP/IP has proven that it is possible :-) -Andi |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: mkfs, Russell Cattelan |
|---|---|
| Next by Date: | Re: mkfs, Jim Bray |
| Previous by Thread: | Re: XFS architecture ?, Ken McDonell |
| Next by Thread: | Re: XFS architecture ?, James Simmons |
| Indexes: | [Date] [Thread] [Top] [All Lists] |