DragonFly kernel List (threaded) for 2007-02
DragonFly BSD
DragonFly kernel List (threaded) for 2007-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Initial filesystem design synopsis.


From: "Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>
Date: Tue, 27 Feb 2007 02:03:05 +0100

Matthew Dillon wrote:
The alternative is to set a specific endianess for the filesystem in
stone, just like the 'network byte order' concept locked in a particular byte ordering for packets. People today STILL hate the
fact that they have to translate certain protocols to network byte
order even when the machines on both ends use the same byte order,
but one that happens to not be 'network' byte order.

But is this really so much effort compared to doing this thing only if the endianness differs between storage and native?


I think code would always look something like:

read data
if (need_conversion)
 convert_data
use data
if (need_conversion)
 convert_data_back
write data

how is that different from:

read data
convert_data
use data
convert_data_back
write_data

yes, sure, there is *always* the conversion. but seriously, that's negligible compared to disk seek/write times.

    We're not making that same mistake, hence the filesystem will be speced
    for endian neutrality even if the code isn't written to support it right
    off the bat.

I don't think having a fixed byte ordering is a mistake. Actually I fear that converting the byte order only if the orders differ might introduce more or at least more obscure bugs.


cheers
 simon

--
Serve - BSD     +++  RENT this banner advert  +++    ASCII Ribbon   /"\
Work - Mac      +++  space for low €€€ NOW!1  +++      Campaign     \ /
Party Enjoy Relax   |   http://dragonflybsd.org      Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz       Mail + News   / \

Attachment: signature.asc
Description: OpenPGP digital signature



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]