FreeLists / openbeos / [openbeos] Re: fs_volume.h vs unistd.h

[Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>]

On 2005-01-03 at 22:22:55 [+0100], François Revol wrote:
> I fixed things in dosfs, but I had a little problem when compiling it
> in R5 without our headers (just copied out the dosfs folder in a
> hurry...)
> 
> NathanW added:
> --- src/add-ons/kernel/file_systems/dos/dosfs.c 21 Mar 2003 21:11:36 -
> 0000      1.3
> +++ src/add-ons/kernel/file_systems/dos/dosfs.c 17 Nov 2004 04:34:56 -
> 0000      1.4
> +#include <fs_volume.h>
> 
> Which isn't an R5 header.
> I commented that line out and it compiled.
> I suppose it used it for the mount flags.
> That brings up an interesting problem.
> Where are those in unistd.h ?
> The mount flags are supposed to be visible from there, at least
> B_MOUNT_READ_ONLY as defined by R5.

We break source compatibility here. The R5 mount() stuff is misplaced in a 
POSIX header, so we decided to move it.

> So do I #include fs_volume.h in unistd (including OS.h too ?)
> or dup the define ?
> or move them to unistd.h and /* see unistd.h for flags */ ?

I'd say neither. We simply break source compatiblity here. The mount API is 
not really pervasively used in BeOS applications (and why should it? :-), 
and we have to provide the mount shell command anyway. Regarding the FS 
add-on side things are even easier: We break both source and binary 
compatibility, so there's no need to care at all.

The situation in the repository is a bit unfortunate at the moment. Our new 
FS interface is not final yet and only the Axel's BFS implements it yet, 
while the other FSs still stick with the R5 interface. In my opinion we 
should just include <fs_volume.h> where needed for the time being. While it 
is certainly not nice, that it doesn't compile on a pure R5 system, it's 
not really our objective either. #ifdef'ing the inclusion of the header 
might be a temporary solution.

CU, Ingo