Re: RFC - new raid superblock layout for md driver

4 messages, 3 authors, 2002-11-21 · open the first message on its own page

Re: RFC - new raid superblock layout for md driver

From: Neil Brown <hidden>
Date: 2002-11-20 23:04:51

On  November 20, alan@lxorguk.ukuu.org.uk wrote:
On Wed, 2002-11-20 at 04:09, Neil Brown wrote:
quoted
    u32  set_uuid[4]
Wouldnt u8 for the uuid avoid a lot of endian mess
Probably....
This makes it very similar to 'name'.  
The difference if partly the intent for how user-space would use it,
and partly that set_uuid must *never* change, while you would probably
want name to be allowed to change.

quoted
    u32  ctime
Use some padding so you can go to 64bit times
Before or after?  Or just make it 64bits of seconds now?
This brings up endian-ness?  Should I assert 'little-endian' or should
the code check the endianness of the magic number and convert if
necessary?
The former is less code which will be exercised more often, so it is
probably safe.

So:
  All values shall be little-endian and times shall be stored in 64
  bits with the top 20 bits representing microseconds (so we & with
  (1<<44)-1  to get seconds.

Thanks.

NeilBrown

Re: RFC - new raid superblock layout for md driver

From: Alan Cox <hidden>
Date: 2002-11-20 23:55:17

On Wed, 2002-11-20 at 23:11, Neil Brown wrote:
This brings up endian-ness?  Should I assert 'little-endian' or should
the code check the endianness of the magic number and convert if
necessary?
The former is less code which will be exercised more often, so it is
probably safe.
From my own experience pick a single endianness otherwise some tool will
always get one endian case wrong on one platform with one word size.
So:
  All values shall be little-endian and times shall be stored in 64
  bits with the top 20 bits representing microseconds (so we & with
  (1<<44)-1  to get seconds.
Could do - or struct timeval or whatever

Re: RFC - new raid superblock layout for md driver

From: Alan Cox <hidden>
Date: 2002-11-20 23:55:24

On Wed, 2002-11-20 at 23:11, Neil Brown wrote:
This brings up endian-ness?  Should I assert 'little-endian' or should
the code check the endianness of the magic number and convert if
necessary?
The former is less code which will be exercised more often, so it is
probably safe.
From my own experience pick a single endianness otherwise some tool will
always get one endian case wrong on one platform with one word size.
So:
  All values shall be little-endian and times shall be stored in 64
  bits with the top 20 bits representing microseconds (so we & with
  (1<<44)-1  to get seconds.
Could do - or struct timeval or whatever

Re: RFC - new raid superblock layout for md driver

From: John Adams <hidden>
Date: 2002-11-21 00:10:17

On Wednesday 20 November 2002 07:30 pm, Alan Cox wrote:
On Wed, 2002-11-20 at 23:11, Neil Brown wrote:
quoted
This brings up endian-ness?  Should I assert 'little-endian' or should
the code check the endianness of the magic number and convert if
necessary?
The former is less code which will be exercised more often, so it is
probably safe.
From my own experience pick a single endianness otherwise some tool will
always get one endian case wrong on one platform with one word size.
Use network byte order. hton[sl] macros already exist.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help