[openbeos] Re: fs_volume.h vs unistd.h
- From: Ingo Weinhold <bonefish@xxxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Mon, 03 Jan 2005 23:26:22 +0100
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
Other related posts:
