public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
* RFC: Changing daddr_t to 64 bits
@ 2020-10-25 21:43 Joel Sherrill
  2020-10-26  9:57 ` Corinna Vinschen
  0 siblings, 1 reply; 3+ messages in thread
From: Joel Sherrill @ 2020-10-25 21:43 UTC (permalink / raw)
  To: Newlib

Hi

The type daddr_t is defined to be long but per some IBM documentation, it
is "used for disk addresses, except in i-nodes on disk. The
*/usr/include/sys/filsys.h* file format describes the format of disk
addresses used in i-nodes."

RTEMS has this in our BSD derived code and 32-bits is too small for disk
addresses. We need it to be 64-bits at least for us.

Can I change it to be 64-bits for all targets?

Thanks.

--joel

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: RFC: Changing daddr_t to 64 bits
  2020-10-25 21:43 RFC: Changing daddr_t to 64 bits Joel Sherrill
@ 2020-10-26  9:57 ` Corinna Vinschen
  2020-10-26 10:53   ` Corinna Vinschen
  0 siblings, 1 reply; 3+ messages in thread
From: Corinna Vinschen @ 2020-10-26  9:57 UTC (permalink / raw)
  To: newlib

On Oct 25 16:43, Joel Sherrill wrote:
> Hi
> 
> The type daddr_t is defined to be long but per some IBM documentation, it
> is "used for disk addresses, except in i-nodes on disk. The
> */usr/include/sys/filsys.h* file format describes the format of disk
> addresses used in i-nodes."
> 
> RTEMS has this in our BSD derived code and 32-bits is too small for disk
> addresses. We need it to be 64-bits at least for us.
> 
> Can I change it to be 64-bits for all targets?

I don't think so.  The existing non-RTEMS definitions should stay
untouched for backward compat.  Noticable is phoenix, which defines
__daddr_t explicitely as __uint32_t.

AFAICS, RTEMS defines __daddr_t not at all.  Just define __daddr_t in
newlib/libc/sys/linux/sys/types.h should fix this up for you.


Thanks,
Corinna


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: RFC: Changing daddr_t to 64 bits
  2020-10-26  9:57 ` Corinna Vinschen
@ 2020-10-26 10:53   ` Corinna Vinschen
  0 siblings, 0 replies; 3+ messages in thread
From: Corinna Vinschen @ 2020-10-26 10:53 UTC (permalink / raw)
  To: newlib

On Oct 26 10:57, Corinna Vinschen via Newlib wrote:
> On Oct 25 16:43, Joel Sherrill wrote:
> > Hi
> > 
> > The type daddr_t is defined to be long but per some IBM documentation, it
> > is "used for disk addresses, except in i-nodes on disk. The
> > */usr/include/sys/filsys.h* file format describes the format of disk
> > addresses used in i-nodes."
> > 
> > RTEMS has this in our BSD derived code and 32-bits is too small for disk
> > addresses. We need it to be 64-bits at least for us.
> > 
> > Can I change it to be 64-bits for all targets?
> 
> I don't think so.  The existing non-RTEMS definitions should stay
> untouched for backward compat.  Noticable is phoenix, which defines
> __daddr_t explicitely as __uint32_t.
> 
> AFAICS, RTEMS defines __daddr_t not at all.  Just define __daddr_t in
> newlib/libc/sys/linux/sys/types.h should fix this up for you.
                  ^^^^^

Probably better newlib/libc/sys/rtems/include/sys/types.h


Sorry,
Corinna


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2020-10-26 10:53 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-25 21:43 RFC: Changing daddr_t to 64 bits Joel Sherrill
2020-10-26  9:57 ` Corinna Vinschen
2020-10-26 10:53   ` Corinna Vinschen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).