[Top] [All Lists]

Re: IRIX clean-ups

To: Daniel Moore <dxm@xxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: IRIX clean-ups
From: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Mon, 16 Oct 2000 11:32:05 -0500
Cc: linux-xfs@xxxxxxxxxxx
References: <200010160540.QAA25336@clouds.melbourne.sgi.com>
Sender: owner-linux-xfs@xxxxxxxxxxx
Daniel Moore wrote:

> I'd like to do some global changes to the tree. Primarily, I'd
> like to switch XFS over to using the standard linux fixed sized
> types.

The intrinsic types should be if any thing: posix compliant.
With other ports of  CXFS starting up anything we do in the
linux XFS tree should remain as portable as possible.
Hopefully this will allow future ports to leverage off the work
we have done.  Also to many linux'ism may discourage any
external developers from doing a new platform.

>         __int8_t                                ->      __s8
>         __uint8_t                               ->      __u8
>         __int16_t                               ->      __s16
>         __uint16_t      &       u_int16_t       ->      __u16
>         __int32_t                               ->      __s32
>         __uint32_t      &       u_int32_t       ->      __u32
>         __int64_t                               ->      __s64
>         __uint64_t                              ->      __u64
>         ulong_t                                 ->      unsigned long
>         uchar_t                                 ->      unsigned char
> And clean up some aliases:
>         linux_off_t                             ->      __kernel_off_t
>         linux_ino_t                             ->      __kernel_ino_t

I would really really  prefer these not be touched just yet.
We spent a bit of time discussing these types.
Anything internal to XFS use xfs_<type>
on the linux side linux_<type>
This  was only applied to overlapping types eg off_t and ino_t
Also since the size of __kernel_<type> may not be fixed across all
architectures it was ruled out for inclusion in actual code.
When and if somebody does port X to architecture X the ino_t and
off_t may need some fiddling with.

The size of ino_t and off_t may be changed in linux at some point
soon. Putting off  changing these types may be a good idea, at least
until there is a direction set by the rest of the community.

> Also, I'd like to replace the bzero, bcopy etc calls with
> their libc style equivalents:
>         bzero(p,s)                              ->      memset((p), 0, (s))
>         bcopy(s,d,n)                            ->      memcpy((d),(s),(n))
>         bcmp(s1,s2,l)                           ->      memcmp(s1,s2,l)
>         ovbcopy(from,to,count)                  ->      memmove(to,from,count)
> This is of course all done with header magic now and it'd be
> nice to lose it.

The mem* functions are fairly standard... probably  wouldn't cause any
portability problems.

> Objections &&|| comments?

> -----------------------------------------------------
>  Daniel Moore                  dxm@xxxxxxx
>  R&D Software Engineer         Phone: +61-3-98348209
>  SGI Performance Tools Group   Fax:   +61-3-98132378
> -----------------------------------------------------

<Prev in Thread] Current Thread [Next in Thread>