Re: [Bug-ddrescue] [PATCH] Add proper device size and name detection on Haiku

[François Revol]

Hi,

On 05/11/2014 19:48, Antonio Diaz Diaz wrote:
> Hello Felix,

Just for the record:

> There are two kinds of platform-specific code that people want to add to
> ddrescue; code that compensates shortcomings in the POSIX implementation
> of a given OS, and code that provides functionality beyond POSIX.
> 
> Of the first kind I am only willing to accept trivial additions, like
> the one for O_BINARY:
> 
>   #ifndef O_BINARY
>   #define O_BINARY 0
>   #endif
> 
> Haiku, for example, has chosen to be compatible with BeOS at both the
> source and binary level, allowing software written and compiled for BeOS
> to be compiled and run without modification on Haiku. Therefore the only

So far it didn't prevent us to add enough POSIX to port all the things
we needed.
The only thing that can cause trouble is the very bad (and linux-only,
it seems BSD never went this ugly) habit of doing "return -EFOO", which
of course will end up quite bad in Haiku since as with BeOS we use
negative error codes.

This violates both POSIX and ANSI C, but well, it's not like POSIX made
up their mind right in the first place (I recall at least one place
where they had "non-zero" and then changed to "positive" about errno).

Using such things as return -EFOO is both ugly and highly error-prone
anyway, I've ported way too many things to Haiku to be proven wrong on
that. :p

POSIX should have been made with negative errors in the first place but
well.

> ways for ddrescue to run on Haiku are:
> 
> a) Haiku implements properly the parts of POSIX that ddrescue needs.
> b) Haiku maintains its own port of ddrescue, as it does with GCC[1].

We do intend to upstream gcc someday.

Unlike BeOS, for which patches were rejected by redhat people
(officially because of a hack to zero-out things when seeking beyond the
file end, but likely also because well, who cares about !Linux), we
fixed most shortcomings BeOS had.

> It is not my fault that OS development has happened in total chaos (just
> like most human enterprises).

Well, it's not like POSIX itself isn't messy in some places, cf. above.

> About the second kind of code additions (providing functionality beyond
> POSIX), mi intention is to implement each feature just once, in the way
> that is best and most probable to be eventualy included in POSIX (by
> default the one working on GNU/Linux).

"best" of course is point-of-view-dependant... but I digress.
There are several things I could list on Linux that are neither the best
nor the first to be implemented. :D

One way to deal with platform discrepancies, which are bound to happen
anyway if you claim portability, and since you use C++, is to have a
Platform class that can be subclassed to override default (POSIX or
stub) behavior...
See BZFlag for a (probably overengineered) example:
http://sourceforge.net/p/bzflag/code/HEAD/tree/trunk/bzflag/src/platform/

I'm sending a revised patch separately with only the device_id() since I
added support for lseek(SEEK_END) on devices in Haiku.

I'll leave the Platform class as a 3rd party opportunity :D

François.