[Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[Anthony Liguori]

Revision: 6324
          http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6324
Author:   aliguori
Date:     2009-01-15 20:44:26 +0000 (Thu, 15 Jan 2009)

Log Message:
-----------
Return -errno on write failure (Gleb Natapov)

Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

Modified Paths:
--------------
    trunk/block-raw-posix.c

Modified: trunk/block-raw-posix.c
===================================================================
--- trunk/block-raw-posix.c	2009-01-15 20:43:39 UTC (rev 6323)
+++ trunk/block-raw-posix.c	2009-01-15 20:44:26 UTC (rev 6324)
@@ -252,7 +252,7 @@
 
     ret = fd_open(bs);
     if (ret < 0)
-        return ret;
+        return -errno;
 
     if (offset >= 0 && lseek(s->fd, offset, SEEK_SET) == (off_t)-1) {
         ++(s->lseek_err_cnt);
@@ -262,7 +262,7 @@
                               s->fd, bs->filename, offset, buf, count,
                               bs->total_sectors, errno, strerror(errno));
         }
-        return -1;
+        return -EIO;
     }
     s->lseek_err_cnt = 0;
 
@@ -277,7 +277,7 @@
 
 label__raw_write__success:
 
-    return ret;
+    return  (ret < 0) ? -errno : ret;
 }
 
 

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[François Revol]

> Revision: 6324
>           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6324
> > Author:   aliguori
> Date:     2009-01-15 20:44:26 +0000 (Thu, 15 Jan 2009)
>
> Log Message:
> -----------
> Return -errno on write failure (Gleb Natapov)

Nooooooooooo
Please do not this bad broken Unix habit!
errno and E* are negative in BeOS and Haiku and sometimes = to
INT32_MIN which means negating it results in positive values or even
overflows.

I've already had too many apps to fix for this.

If you want to know why this violates standards, use IPOT and ask Be,
Inc. But it's not gonna change soon. And also ask Opengroup why they
changed their mind later on after only requiring them to be !=0. Shame
on them.

It's IMO much cleaner and logical after seeing many misplaced signs in
various software on that, but I don't expect to change it on Unix
anyway, I just ask our way be respected as well.

If you really want to pass the error this way, at least make sure they
are signed correctly.
See http://svn.ffmpeg.org/ffmpeg/trunk/libavcodec/avcodec.h?revision=16580&view=markup

#if EINVAL > 0
#define QERROR(e) (-(e)) /**< Returns a negative error code from a
POSIX error code, to return from library functions. */
#define QUNERROR(e) (-(e)) /**< Returns a POSIX error code from a
library function error return value. */
#else
/* Some platforms have E* and errno already negated. */
#define QERROR(e) (e)
#define QUNERROR(e) (e)
#endif

and return QERROR(errno) or return QERROR(EINVAL);

This has been used in FFmpeg and many other things and works very well.

In OSS4 they chose to define their own error codes from E* at configure
time, but I find it more intrusive.

François.

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[M. Warner Losh]

In message: <2858981241-BeMail@laptop>
            "François Revol" <revol@free.fr> writes:
: > Revision: 6324
: >           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6324
: > > Author:   aliguori
: > Date:     2009-01-15 20:44:26 +0000 (Thu, 15 Jan 2009)
: > 
: > Log Message:
: > -----------
: > Return -errno on write failure (Gleb Natapov)
: 
: Nooooooooooo
: Please do not this bad broken Unix habit!

s/Unix/Linux/

Warner

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[François Revol]

> In message: <2858981241-BeMail@laptop>
>             "François Revol" <revol@free.fr> writes:
> : > Revision: 6324
> : >           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6324
> > : > > Author:   aliguori
> : > Date:     2009-01-15 20:44:26 +0000 (Thu, 15 Jan 2009)
> : >
> : > Log Message:
> : > -----------
> : > Return -errno on write failure (Gleb Natapov)
> :
> : Nooooooooooo
> : Please do not this bad broken Unix habit!
>
> s/Unix/Linux/

I didn't want to sound inquisitory, but indeed most uses I've seen come
from Linux code or linux devs, though OSSv4 had it quite everywhere.

It's actually fairly common inside Unix kernels themselves.
There it's absolutely no problem since it's by definition code that
only targets a single OS. But I've seen more and more userland (and
portable kernel) code using this bad trick without consideration for
other platforms.

The fact that it's "standardized" doesn't make it better for real world
implementations that do depart from the standard.
And Opengroup screwing up didn't help:
http://www.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html#tag_13_10_10

I'll try to make a patch to correct this.

François.

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[Gleb Natapov]

On Thu, Jan 15, 2009 at 10:20:33PM +0100, François Revol wrote:
> > Revision: 6324
> >           http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6324
> > > Author:   aliguori
> > Date:     2009-01-15 20:44:26 +0000 (Thu, 15 Jan 2009)
> >
> > Log Message:
> > -----------
> > Return -errno on write failure (Gleb Natapov)
> 
> Nooooooooooo
> Please do not this bad broken Unix habit!
> errno and E* are negative in BeOS and Haiku and sometimes = to
> INT32_MIN which means negating it results in positive values or even
> overflows.
> 
This is how qemu block layer passes error reason to the caller. Not only
here but in other places too.

> 
> #if EINVAL > 0
> #define QERROR(e) (-(e)) /**< Returns a negative error code from a
> POSIX error code, to return from library functions. */
> #define QUNERROR(e) (-(e)) /**< Returns a POSIX error code from a
> library function error return value. */
> #else
> /* Some platforms have E* and errno already negated. */
> #define QERROR(e) (e)
> #define QUNERROR(e) (e)
> #endif
> 
> and return QERROR(errno) or return QERROR(EINVAL);
>
Patch to fix qemu on BeOS are welcomed :)
 
--
			Gleb.

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[Ian Jackson]

François Revol writes ("Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)"):
> Nooooooooooo
> Please do not this bad broken Unix habit!

Whatever you think of this, it's not a `Unix habit'.
Both C89 and C99 require the system's errno values to be positive.
   ... the value of which is set to a positive error number by 
       several library functions

So BeOS is not ANSI C !

Ian.

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[François Revol]

> François Revol writes ("Re: [Qemu-devel] [6324] Return -errno on
> write failure (Gleb Natapov)"):
> > Nooooooooooo
> > Please do not this bad broken Unix habit!
>
> Whatever you think of this, it's not a `Unix habit'.
> Both C89 and C99 require the system's errno values to be positive.
>    ... the value of which is set to a positive error number by
>        several library functions
>
> So BeOS is not ANSI C !

And so, well, what ?
It won't change any time soon.
Besides, there is no reason a language stantard should dictate such a
runtime thing...
And for what I've seen from it, it's not consistent with itself, saying
non-zero on a line, positive on the next one.

Btw, was it available freely at the time ? I mean don't expect people
to comply with something you have to pay for. That's what you get.
(hint, POSIX drafts)

It's not like any other OS I've seen doesn't violate some standard.

Still, everything has been fine for a decade and suddenly people start
doing this kind of tricks out of the blue. It's not like considering
errno can be !=0 is orthogonal to the standard, so supporting BeOS
itself would't make the code itself violate ANSI C.

François.

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[Anthony Liguori]

François Revol wrote:
>> So BeOS is not ANSI C !
>>     
>
> And so, well, what ?
> It won't change any time soon.
> Besides, there is no reason a language stantard should dictate such a 
> runtime thing...
> And for what I've seen from it, it's not consistent with itself, saying 
> non-zero on a line, positive on the next one.
>
> Btw, was it available freely at the time ? I mean don't expect people 
> to comply with something you have to pay for. That's what you get. 
> (hint, POSIX drafts)
>
> It's not like any other OS I've seen doesn't violate some standard.
>
> Still, everything has been fine for a decade and suddenly people start 
> doing this kind of tricks out of the blue. It's not like considering 
> errno can be !=0 is orthogonal to the standard, so supporting BeOS 
> itself would't make the code itself violate ANSI C.
>   

If a full set of patches was posted that to QEMU that made the latest 
SVN compile on BeOS with a free compiler, I would think we would 
evaluate them and determine how intrusive the changes were compared to 
the value of supporting BeOS and apply them if appropriate.  Avoiding 
-errno, IMHO, is a fair trade off to support another platform even if 
there is a niche user base.

That said, such patches have not been posted.  I don't think it's wise 
to get into a habit of avoiding things because some random platform that 
QEMU doesn't support today doesn't support said feature.

So I'm not inclined to change code that conforms to ANSI unless someone 
puts the work into supporting BeOS in mainline QEMU and that said work 
doesn't require very invasive changes.

Regards,

Anthony Liguori

> François.
>
>
>   

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[François Revol]

> If a full set of patches was posted that to QEMU that made the latest
> SVN compile on BeOS with a free compiler, I would think we would
> evaluate them and determine how intrusive the changes were compared
> to
> the value of supporting BeOS and apply them if appropriate.  Avoiding
> -errno, IMHO, is a fair trade off to support another platform even if
> there is a niche user base.

I don't have time to do it right away, but it's on my list.

> That said, such patches have not been posted.  I don't think it's
> wise
> to get into a habit of avoiding things because some random platform
> that
> QEMU doesn't support today doesn't support said feature.

There is a BeOS port already.
I just think noone noticed this issue so it wasn't concerned by the
patches, but there are patches.
I have an old one around but I don't even recall what it fixes:
http://revolf.free.fr/beos/patches/qemu-0.7.1.beos.patch.001.txt

The maintainer of our port didn't submit patches because he was too
busy to clean it up AFAIK.
I'm not even sure it'd still build on BeOS, but that'd certainly help
building in Haiku.

> So I'm not inclined to change code that conforms to ANSI unless
> someone
> puts the work into supporting BeOS in mainline QEMU and that said
> work
> doesn't require very invasive changes.

As per other ports, it's not invasive it's just a large diff and it's
fastidious to make sure each and every occurence is fixed.
something like:
http://revolf.free.fr/beos/patches/ffmpeg_beos_cleanup.002.diff
or
http://revolf.free.fr/beos/patches/oss-hg-365-beos.diff.txt

François.

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[Anthony Liguori]

François Revol wrote:
> The maintainer of our port didn't submit patches because he was too 
> busy to clean it up AFAIK.
> I'm not even sure it'd still build on BeOS, but that'd certainly help 
> building in Haiku.
>
>   
>> So I'm not inclined to change code that conforms to ANSI unless 
>> someone 
>> puts the work into supporting BeOS in mainline QEMU and that said 
>> work 
>> doesn't require very invasive changes.
>>     
>
> As per other ports, it's not invasive it's just a large diff and it's 
> fastidious to make sure each and every occurence is fixed.
>   

Which is a good encouragement to invest the time in pushing your work 
upstream.  It's unfair to ask upstream QEMU to make changes to make 
external ports simpler to maintain though.

Regards,

Anthony Liguori

> something like:
> http://revolf.free.fr/beos/patches/ffmpeg_beos_cleanup.002.diff
> or
> http://revolf.free.fr/beos/patches/oss-hg-365-beos.diff.txt
>
> François.
>
>
>   

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[François Revol]

> > The maintainer of our port didn't submit patches because he was too
> > busy to clean it up AFAIK.
> > I'm not even sure it'd still build on BeOS, but that'd certainly
> > help
> > building in Haiku.
> >
> >
> >> So I'm not inclined to change code that conforms to ANSI unless
> >> someone
> >> puts the work into supporting BeOS in mainline QEMU and that said
> >> work
> >> doesn't require very invasive changes.
> >>
> >
> > As per other ports, it's not invasive it's just a large diff and
> > it's
> > fastidious to make sure each and every occurence is fixed.
> >
>
> Which is a good encouragement to invest the time in pushing your work
> upstream.  It's unfair to ask upstream QEMU to make changes to make
> external ports simpler to maintain though.

Who said I asked you to do it ?
I said I would.
And it's not to make it simpler to maintain outside. It's just to make
sure it's known, and make it simpler to push the rest upstream, because
I'm used to this issue.

I don't control what others do. As for me I usually send diffs early so
I don't have to maintain forks because I know how time consuming it is.

François.

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[Ian Jackson]

François Revol writes ("Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)"):
> [Ian Jackson:]
> > So BeOS is not ANSI C !
> 
> And so, well, what ?

You were complaining, in your original message, that the POSIX people
had changed their specification.  However POSIX has always been
supposed to follow C89 and later C99 on this subject.  C89 has always
said that errno values are positive.

Before C89 there was no detailed standard for C at all; errno was
defined by the context of its invention - ie, Unix.

It seems amazing that an operating system written in the 1990s can
manage to be non-complaint on such a basic point.  It's not like C89
is some kind of weird Unix-specific thing.  It was written to
encompass all of MS-DOS, Apple and IBM mainframes (as well as Unix of
course).

> It won't change any time soon.

Maybe users of such badly defective operating systems should live with
the costs of the bug.  If it were just a single place to make a
workaround, there would be no argument; qemu has many such
workarounds.  But the current proposal is to change lots of code
throughout qemu.

But returning -errno to indicate an error is a very convenient
practice.  It is deservedly widely used, not just in qemu.  To do
things another way would make much of the code much more verbose.

Why should the rest of the world have to bear that cost - in the form
of increased effort in maintenance, increased bug rates,
incompatibility of patches made against different versions of qemu,
and so on ?

Instead, developers using BeOS should probably provide some kind of
compatibility shim so that correct programs can work properly.
Failing that you should maintaining the intrusive patch yourselves
rather than imposing it on the rest of us.



The rest of your article is full of pointless railing against
standards, but lest I be accused of not having answers:

> Besides, there is no reason a language stantard should dictate such a
> runtime thing...

errno is defined in C89 and C99 along with the rest of the C standard
library.  So if have an excessively narrow view of what a `language
standard' is then ANSI C is a `language and library standard'.

> And for what I've seen from it, it's not consistent with itself, saying
> non-zero on a line, positive on the next one.

It says `non-zero' for emphasis, to ensure that the reader will
interpret it as strictly positive rather than just non-negative.  You
will note of course that positive numbers are positive and also
non-zero, so there is no contradiction.  Negative numbers are non-zero
but not positive so not permitted.

> Btw, was it available freely at the time ? I mean don't expect people
> to comply with something you have to pay for. That's what you get.
> (hint, POSIX drafts)

Are you telling me that Be Inc couldn't afford a copy of the
specification for the C programming language while they were writing
their operating system ?

If BeOS had been a Free operating system then someone would probably
have pointed this error out to them sooner.

> It's not like any other OS I've seen doesn't violate some standard.

The workarounds for other don't aren't intrusive and incompatible-
across-versions internal API changes in the form of textually large
patches.

> Still, everything has been fine for a decade and suddenly people start
> doing this kind of tricks out of the blue.

Nonsense.  People have been passing -errno in application code for
decades.  Evidently not in code you've previously encountered.

>  It's not like considering errno can be !=0 is orthogonal to the
> standard, so supporting BeOS itself would't make the code itself
> violate ANSI C.

But it would make the code longer and more clumsy and more
complicated.  That increases the expected number of bugs.

Ian.

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[François Revol]

> > > So BeOS is not ANSI C !
> >
> > And so, well, what ?
>
> You were complaining, in your original message, that the POSIX people
> had changed their specification.  However POSIX has always been
> supposed to follow C89 and later C99 on this subject.  C89 has always
> said that errno values are positive.

It doesn't change the fact they did change their text at one point.

> Before C89 there was no detailed standard for C at all; errno was
> defined by the context of its invention - ie, Unix.

Unix was just taken as a defacto standard and standardized into it.
But why would it be better than others ? (appart author relationship
with C itself)

> It seems amazing that an operating system written in the 1990s can
> manage to be non-complaint on such a basic point.  It's not like C89
> is some kind of weird Unix-specific thing.  It was written to
> encompass all of MS-DOS, Apple and IBM mainframes (as well as Unix of
> course).

BeOS is not so new, and C89 was probably not widespread at the time,
just see how long it got to gcc to conform...
http://en.wikipedia.org/wiki/BeOS

There is also the fact that at least theorically one has to pay for it,
unlike RFCs. It's interesting to see free software people insisting on
Microsoft or others for free of charge specs on protocols yet abide by
paid standards.

> > It won't change any time soon.
>
> Maybe users of such badly defective operating systems should live
> with
> the costs of the bug.  If it were just a single place to make a
> workaround, there would be no argument; qemu has many such
> workarounds.  But the current proposal is to change lots of code
> throughout qemu.

There I don't want to even try to argue anymore.
non-conformant != defective.

I could also say C89 is defective in its design by not taking the
cleanest approach, since having EDOM < 0 in the first place removes a
lot of potential bugs by not forgetting the - everywhere.

BeOS has been created this way. Saying it's defective is both wrong and
insulting.
I don't feel like answering the rest either...

> But returning -errno to indicate an error is a very convenient
> practice.  It is deservedly widely used, not just in qemu.  To do

I'm still wondering why this convenient way of doing has not been used
for decades outside Unix kernels themselves until recently...

> things another way would make much of the code much more verbose.

It might look convenient but exposes to missing - everywhere too...

> Why should the rest of the world have to bear that cost - in the form
> of increased effort in maintenance, increased bug rates,
> incompatibility of patches made against different versions of qemu,
> and so on ?

I'd say calling a macro of whatever could also make it more obvious and
could bring more attention to a potential source of bug.

> Instead, developers using BeOS should probably provide some kind of
> compatibility shim so that correct programs can work properly.
> Failing that you should maintaining the intrusive patch yourselves
> rather than imposing it on the rest of us.

BeOS probably not, it's closed source.
As for Haiku, well, feel free to send a patch but I don't see how one
can come up with a sensible way of doing it considering those are used
everywhere.

And I still think it's the cleanest way, regardless standards.

We are not alone doing that, there is Minix also, though they OTOH
change the signness of theirs depending on the context (kernel vs
user), which IMO is quite ugly and error prone. At least they conform
to ANSI C at user level... but not kernel.

> > Besides, there is no reason a language stantard should dictate such
> > a
> > runtime thing...
>
> errno is defined in C89 and C99 along with the rest of the C standard
> library.  So if have an excessively narrow view of what a `language
> standard' is then ANSI C is a `language and library standard'.

Either way, after seeing how the drafts I found talks about it I don't
see why I would comply to it, it's like "oh EDOM is positive, but errno
is assigned a non zero value on error, oh but it must be assigned to
EDOM in that case, which is non-zero, but oh, errno should or must or
I'm not sure what I'm writing anymore but possibly it's positive".
I do hope the final one is fixed.

At least depending how you read it sometimes you might think despite
EDOM and ERANGE should be >0 it doesn't mean errno would always be >0.

And again, in POSIX, there is a single place where the signedness is
explained, and this place has been "fixed" to comply with C99 at some
point.

Not counting all the "implementation defined" cases where we would
really like to know what to do.

> > And for what I've seen from it, it's not consistent with itself,
> > saying
> > non-zero on a line, positive on the next one.
>
> It says `non-zero' for emphasis, to ensure that the reader will
> interpret it as strictly positive rather than just non-negative.  You
> will note of course that positive numbers are positive and also
> non-zero, so there is no contradiction.  Negative numbers are non-
> zero
> but not positive so not permitted.

One could also just say "positive and non-zero" or "strictly positive".
In any case it brings contradiction by trying to wave another
contradiction.

> > Btw, was it available freely at the time ? I mean don't expect
> > people
> > to comply with something you have to pay for. That's what you get.
> > (hint, POSIX drafts)
>
> Are you telling me that Be Inc couldn't afford a copy of the
> specification for the C programming language while they were writing
> their operating system ?

I did not work at Be, mail them via IPOT if you will...

> If BeOS had been a Free operating system then someone would probably
> have pointed this error out to them sooner.

The headers were available in the SDK download for free for a decade.

> > It's not like any other OS I've seen doesn't violate some standard.
>
> The workarounds for other don't aren't intrusive and incompatible-
> across-versions internal API changes in the form of textually large
> patches.

As I said it's not intrusive, it's just fastidious to do once.
And it does not change any API or ABI on other OSes.

A function that returned -EINVAL in linux before would still return -
EINVAL.
It is transparent to other OSes, and just ensures correct signedness/
non overflow on BeOS and Haiku.

> > Still, everything has been fine for a decade and suddenly people
> > start
> > doing this kind of tricks out of the blue.
>
> Nonsense.  People have been passing -errno in application code for
> decades.  Evidently not in code you've previously encountered.

And I did encounter lot of code... maybe not enough.

> >  It's not like considering errno can be !=0 is orthogonal to the
> > standard, so supporting BeOS itself would't make the code itself
> > violate ANSI C.
>
> But it would make the code longer and more clumsy and more
> complicated.  That increases the expected number of bugs.

It's also possible to define QEINVAL and friends as [-]EINVAL.
There,
return -EINVAL;
becomes
return QEINVAL;

No single byte more when returning constants, it just doesn't work for
errno itself...
It does remove the possibility of missing the - OTH.

It's what OSS did.
Not my prefered but it works as well.

François.

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[Lennart Sorensen]

On Mon, Jan 19, 2009 at 07:52:03PM +0100, Fran??ois Revol wrote:
> There is also the fact that at least theorically one has to pay for it,
> unlike RFCs. It's interesting to see free software people insisting on
> Microsoft or others for free of charge specs on protocols yet abide by
> paid standards.

Open source people want to be able to get specs.  Having to pay for the
paper it is printed on isn't that bad.  Not being able to get it at all
is bad.  I think Epson has traditionally charged about $20 or so for
programing specs for their inkjet printers, although I could have that
figure wrong (I have never had to order one since the gutenprint people
do such a great job already),and they might even be giving free copies
to some groups.  Nothing wrong with that.

Open source is NOT about not costing money, it is about being able to
get sources and specs and do stuff with them.

-- 
Len Sorensen

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[M. Warner Losh]

In message: <7523661163-BeMail@laptop>
            "François Revol" <revol@free.fr> writes:
: > But returning -errno to indicate an error is a very convenient
: > practice.  It is deservedly widely used, not just in qemu.  To do
: 
: I'm still wondering why this convenient way of doing has not been used 
: for decades outside Unix kernels themselves until recently...

s/Unix/Linux/g.  This is a Linuxism that isn't widespread outside of
Linux and programs that were written to emulate the Linux -EBLAH style
in the Linux kernel.  BSD doesn't do this at all, nor does Solaris or
the antecedents of SysV, 8th edition, seventh edition, sixth edition,
etc.  The Linux kernel was the first place I saw the practice, which
many have panned as unwise in-band signaling since it tries to encode
in part of the range of the return value the error, when in fact you
can't always assume that all system-call functions will return a
negative number that's not meaningful (which is why the standards are
very careful to specify that the return value of the system call is
-1, and errno is set to provide more information about the error).

So please, let's not get carried away and claim that this practice
originated in Unix, nor tar the whole Unix world with this dubious
practice.  Of course, the polemics on this thread are already out of
this world, and I should know better than to reply...

Warner

Re: [Qemu-devel] [6324] Return -errno on write failure (Gleb Natapov)

[François Revol]

> On Mon, Jan 19, 2009 at 07:52:03PM +0100, Fran??ois Revol wrote:
> > There is also the fact that at least theorically one has to pay for
> > it,
> > unlike RFCs. It's interesting to see free software people insisting
> > on
> > Microsoft or others for free of charge specs on protocols yet abide
> > by
> > paid standards.
>
> Open source people want to be able to get specs.  Having to pay for
> the
> paper it is printed on isn't that bad.  Not being able to get it at
> all
> is bad.  I think Epson has traditionally charged about $20 or so for
> programing specs for their inkjet printers, although I could have
> that
> figure wrong (I have never had to order one since the gutenprint
> people
> do such a great job already),and they might even be giving free
> copies
> to some groups.  Nothing wrong with that.
>
> Open source is NOT about not costing money, it is about being able to
> get sources and specs and do stuff with them.

That was just to point out the dilemna, yes it's not a problem to
charge for paper prints, and even the GPL allows charging for the
shipping costs, but nowadays it's so easy to have a file on an ftp/http
server that not doing so shows a lot about openness. Plus I'm not sure
the fees for C89 were only about printing at the time... (and printing
fees for 10 pages is not the same as for 500 pages...).

François.