[9fans] libbio and large files

[9fans] libbio and large files

[Jeff Sickel]

This question may be more applicable when addressing p9p on other
systems:

I'm seeking a little clarification about Bopen and reading through
files larger than (2^31 bytes).  Other host systems where p9p works
(very well I might add) tend to have different definitions for off_t
depending on 32/64 bit support (some require off64_t while others do
contortions around redefining off_t depending on the joy of compiler
flags, both leading to other incantations that may require
orthodontia), how does one go about ensuring that their host OS does
properly access large files properly when using libbio?

Also--shouldn't binit.c:125 in p9p be updated to the changes found on
sources?

cpu % history -D binit.c
...
/n/sourcesdump/2008/0430/plan9/sys/src/libbio/binit.c:108 c /n/
sourcesdump/2005/0829/plan9/sys/src/libbio/binit.c:108
< 		f = open(name, mode);
---
 > 		f = open(name, OREAD);
...


-jas

Re: [9fans] libbio and large files

[Russ Cox]

> This question may be more applicable when addressing p9p on other
> systems:
>
> I'm seeking a little clarification about Bopen and reading through
> files larger than (2^31 bytes).  Other host systems where p9p works
> (very well I might add) tend to have different definitions for off_t
> depending on 32/64 bit support (some require off64_t while others do
> contortions around redefining off_t depending on the joy of compiler
> flags, both leading to other incantations that may require
> orthodontia), how does one go about ensuring that their host OS does
> properly access large files properly when using libbio?

These considerations are supposed to be hidden from you:
the Plan 9 interfaces all assume 64-bit file offset sizes,
and the underlying implementations contain the right magic goo
to pass those sizes, untruncated, to the underlying operating system.
The magic goo typically takes the form of #defines in u.h.

Intro(3) reads:

          Plan 9 and Unix use many similarly-named functions for dif-
          ferent purposes: for example, Plan 9's dup is closer to (but
          not exactly) Unix's dup2. To avoid name conflicts, <libc.h>
          defines many of these names as preprocessor macros to add a
          p9 prefix, so that dup becomes p9dup. To disable this renam-
          ing, #define NOPLAN9DEFINES before including <libc.h>.  If
          Unix headers must be included in a program, they should be
          included after <u.h>, which sets important preprocessor
          directives (for example, to enable 64-bit file offsets), but
          before <libc.h>, to avoid renaming problems.

When reading libbio or any p9p program, you should remember that
a call to open is really a call to p9open, and similarly a call to
seek is really a call to p9seek.

If you have a system on which u.h does not manage to set up 64-bit
file offsets, I'd like to hear about it.  I don't know of any that use
off64_t as the only possible way to get them.


That said, libbio has a somewhat odd dual role, though, since it builds
both for p9p and as a standalone Unix library from the same
sources.  Because of this heritage, it had been using off_t
and hoping that the environment was set up properly so that
off_t meant 64 bits.  I have changed these in bio.h to "long long",
so that there can be no mistake at the call sites, and I added the
right #defines to its compatibility header ($PLAN9/src/libbio/lib9.std.h).

> Also--shouldn't binit.c:125 in p9p be updated to the changes found on
> sources?

Yes, done.  I also changed the in-p9p binit to use
create (p9create) instead of creat.

Russ