Linux should define ENOTSUP

Linux should define ENOTSUP

[Samuel Thibault]

Hi,

ENOTSUP is not used at all by linux (though it is defined for parisc),
while as susv3 specifies, ENOTSUP shall be different than EOPNOTSUPP.
Is there a reason for doing so? (except history)

Currently, code like

switch(errno) {
	ENOTSUP:
		foo();
		break;
	EOPNOTSUP:
		bar();
		break;
}
just can't compile...

Is there any way to fix this?  Glibc people don't seem to want to fix it
on their part, see
http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363

Samuel

Re: Linux should define ENOTSUP

[Arjan van de Ven]

> Is there any way to fix this?  Glibc people don't seem to want to fix it
> on their part, see
> http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363

Hi,

Ulrich asked you to go to us once your time travel machine was
finished.. is it finished yet ?  ;=)


this is part of the ABI, so we can't change this in 2006...

Greetings,
   Arjan van de Ven


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: Linux should define ENOTSUP

[Samuel Thibault]

Hi,

Arjan van de Ven, le Wed 06 Dec 2006 15:25:14 +0100, a écrit :
> 
> > Is there any way to fix this?  Glibc people don't seem to want to fix it
> > on their part, see
> > http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363
> 
> Ulrich asked you to go to us once your time travel machine was
> finished.. is it finished yet ?  ;=)

;)

> this is part of the ABI, so we can't change this in 2006...

Ok, so Linux will never be fully posix compliant.

Samuel

Re: Linux should define ENOTSUP

[H. Peter Anvin]

Arjan van de Ven wrote:
>> Is there any way to fix this?  Glibc people don't seem to want to fix it
>> on their part, see
>> http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363
> 
> Hi,
> 
> Ulrich asked you to go to us once your time travel machine was
> finished.. is it finished yet ?  ;=)
> 
> this is part of the ABI, so we can't change this in 2006...
> 

If ENOTSUP is currently unused and is only there for completeness, then 
it should be fine to add it.

	-hpa

Re: Linux should define ENOTSUP

[H. Peter Anvin]

Samuel Thibault wrote:
> 
>> this is part of the ABI, so we can't change this in 2006...
> 
> Ok, so Linux will never be fully posix compliant.
> 

That's largely already the case, mostly because there is unfortunately 
still a fair bit of rubber-stamping Solaris going on.

	-hpa

Re: Linux should define ENOTSUP

[Samuel Thibault]

H. Peter Anvin, le Wed 06 Dec 2006 07:16:39 -0800, a écrit :
> Arjan van de Ven wrote:
> >>Is there any way to fix this?  Glibc people don't seem to want to fix it
> >>on their part, see
> >>http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363
> >
> >Hi,
> >
> >Ulrich asked you to go to us once your time travel machine was
> >finished.. is it finished yet ?  ;=)
> >
> >this is part of the ABI, so we can't change this in 2006...
> >
> 
> If ENOTSUP is currently unused and is only there for completeness, then 
> it should be fine to add it.

The functions that should be returning it instead of EOPNOTSUP should be
fixed too.

Samuel

Re: Linux should define ENOTSUP

[H. Peter Anvin]

Samuel Thibault wrote:
> H. Peter Anvin, le Wed 06 Dec 2006 07:16:39 -0800, a écrit :
>> Arjan van de Ven wrote:
>>>> Is there any way to fix this?  Glibc people don't seem to want to fix it
>>>> on their part, see
>>>> http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363
>>> Hi,
>>>
>>> Ulrich asked you to go to us once your time travel machine was
>>> finished.. is it finished yet ?  ;=)
>>>
>>> this is part of the ABI, so we can't change this in 2006...
>>>
>> If ENOTSUP is currently unused and is only there for completeness, then 
>> it should be fine to add it.
> 
> The functions that should be returning it instead of EOPNOTSUP should be
> fixed too.
> 

The two can't be done at the same time.  In fact, the two probably can't 
be done without a period of quite a few *years* between them.

	-hpa

Re: Linux should define ENOTSUP

[Samuel Thibault]

H. Peter Anvin, le Wed 06 Dec 2006 07:26:44 -0800, a écrit :
> Samuel Thibault wrote:
> >H. Peter Anvin, le Wed 06 Dec 2006 07:16:39 -0800, a écrit :
> >>Arjan van de Ven wrote:
> >>>>Is there any way to fix this?  Glibc people don't seem to want to fix it
> >>>>on their part, see
> >>>>http://sources.redhat.com/bugzilla/show_bug.cgi?id=2363
> >>>Hi,
> >>>
> >>>Ulrich asked you to go to us once your time travel machine was
> >>>finished.. is it finished yet ?  ;=)
> >>>
> >>>this is part of the ABI, so we can't change this in 2006...
> >>>
> >>If ENOTSUP is currently unused and is only there for completeness, then 
> >>it should be fine to add it.
> >
> >The functions that should be returning it instead of EOPNOTSUP should be
> >fixed too.
> >
> 
> The two can't be done at the same time.  In fact, the two probably can't 
> be done without a period of quite a few *years* between them.

Not a reason for not doing it ;)

Samuel

Re: Linux should define ENOTSUP

[H. Peter Anvin]

Samuel Thibault wrote:
>> The two can't be done at the same time.  In fact, the two probably can't 
>> be done without a period of quite a few *years* between them.
> 
> Not a reason for not doing it ;)

No, but breakage is.  There has to be a major benefit to justify the 
cost, and you, at least, have not provided such a justification.

	-hpa

Re: Linux should define ENOTSUP

[Samuel Thibault]

H. Peter Anvin, le Wed 06 Dec 2006 07:35:49 -0800, a écrit :
> Samuel Thibault wrote:
> >>The two can't be done at the same time.  In fact, the two probably can't 
> >>be done without a period of quite a few *years* between them.
> >
> >Not a reason for not doing it ;)
> 
> No, but breakage is.  There has to be a major benefit to justify the 
> cost, and you, at least, have not provided such a justification.

Well, as I said, existing code like

switch(errno) {
	case ENOTSUP:
		foo();
		break;
	case EOPNOTSUP:
		bar();
		break;
}

Samuel

Re: Linux should define ENOTSUP

[H. Peter Anvin]

Samuel Thibault wrote:
> H. Peter Anvin, le Wed 06 Dec 2006 07:35:49 -0800, a écrit :
>> Samuel Thibault wrote:
>>>> The two can't be done at the same time.  In fact, the two probably can't 
>>>> be done without a period of quite a few *years* between them.
>>> Not a reason for not doing it ;)
>> No, but breakage is.  There has to be a major benefit to justify the 
>> cost, and you, at least, have not provided such a justification.
> 
> Well, as I said, existing code like
> 
> switch(errno) {
> 	case ENOTSUP:
> 		foo();
> 		break;
> 	case EOPNOTSUP:
> 		bar();
> 		break;
> }
> 

That's pretty weak, though.

	-hpa

Re: Linux should define ENOTSUP

[Ulrich Drepper]

On 12/6/06, H. Peter Anvin <hpa@zytor.com> wrote:
> That's largely already the case, mostly because there is unfortunately
> still a fair bit of rubber-stamping Solaris going on.

Don't say that, Peter.

I'm working on the committee now for many years and got most changes I
(and those telling me their wishes) wanted through.  This is very much
a technically oriented working group, not political.  In fact, of the
regular members there are more with stakes in Linux than any of the
other OSes combined.  If there are problems people perceive they can
file bugs on the OpenGroup's site
(http://www.opengroup.org/austin/defectform.html) or tell me about it.

About the issue at hand: if the original poster would have taken the
time to investigate the issue he would have seen that this topic was
discussed (I think we handled it in September in Reading).  See

http://www.opengroup.org/austin/aardvark/latest/xbdbug2.txt

The statement about the interpretations track means that the change
will be made to the current standard, not only the next revision.

There is no need to change anything in kernel or libc.  Code using
both values in a switch statement is out of luck but a) this is really
really rare (nobody should reimplement strerror) and b) can be easily
fixed.

Re: Linux should define ENOTSUP

[H. Peter Anvin]

Ulrich Drepper wrote:
> On 12/6/06, H. Peter Anvin <hpa@zytor.com> wrote:
>> That's largely already the case, mostly because there is unfortunately
>> still a fair bit of rubber-stamping Solaris going on.
> 
> Don't say that, Peter.
> 
> I'm working on the committee now for many years and got most changes I
> (and those telling me their wishes) wanted through.  This is very much
> a technically oriented working group, not political.  In fact, of the
> regular members there are more with stakes in Linux than any of the
> other OSes combined.  If there are problems people perceive they can
> file bugs on the OpenGroup's site
> (http://www.opengroup.org/austin/defectform.html) or tell me about it.
> 

I'm quite aware of that, but I still think Sun has more resources to get 
their particular viewpoint through the committee -- it's just a matter 
of resources at hand.  I myself had to largely drop out due to other 
pressures, for example.

Now, I'm much happier with Solaris being rubber-stamped than some other 
possibilities.  However, it's very easy to sweep concerns under the rug 
by saying "legacy, out of scope."

	-hpa

Re: Linux should define ENOTSUP

[Ulrich Drepper]

On 12/6/06, H. Peter Anvin <hpa@zytor.com> wrote:
> I'm quite aware of that, but I still think Sun has more resources to get
> their particular viewpoint through the committee -- it's just a matter
> of resources at hand.  I myself had to largely drop out due to other
> pressures, for example.

But I'm still there, as are IBM, HP people and various other
organizations.  Sun is represented by one person and all the direct
influence the company has is in the OpenGroup vote (one of three).
And here the field is even wider, many more companies have a vote
(including Red Hat).  The other two organizations are IEEE (where the
members of the balloting group make the decisions, individuals but
also implementer votes) and ISO (which is entirely country based).

It is simply not true that any OS manufacturer has any power like
this.  At least not in the last 8 years or so.  And as I said before,
if you can potentially say this about any OS then it is Linux.  The
ENOTSUP issue is a good example.  There is no need for this change in
any of the certified Unixes (since they got there errno assingments
from SysV or at least tested against the Unix test suite early on).
The pressure from the growing number of Linux users made this an issue
and so it got changed.

And take a look at the next revision.  This is mostly an "align with
Linux" edition since Linux already has all the proposed new
functionality.  Solaris has only a small subset and none of the other
OS have anything like it.

Re: Linux should define ENOTSUP

[Theodore Tso]

On Wed, Dec 06, 2006 at 03:31:59PM +0100, Samuel Thibault wrote:
> 
> Ok, so Linux will never be fully posix compliant.

?

Can you please quote chapter and verse (in POSIX) where it states that
ENOTSUP and EOPNOTSUP have to be numerically distinct?  If you are
reading Unix 98 you might be able to make a claim that there is an
implication that they be assigned unique error numbers, but it's at
best an implication, not an explicitly specified requirement in any of
the standards documents that I'm aware of.

To folks who are participating in the committee doing work on the
upcoming POSIX revisions (which might make this a requirement to be
imposed on us in a year or two) --- will that likely impose such a
requirement?  In that case we might want to start thinking about
separating the two, but it really is a question of is the benefits are
worth the effort.

						- Ted

Re: Linux should define ENOTSUP

[Andreas Schwab]

Theodore Tso <tytso@mit.edu> writes:

> Can you please quote chapter and verse (in POSIX) where it states that
> ENOTSUP and EOPNOTSUP have to be numerically distinct?

<http://www.opengroup.org/onlinepubs/009695399/basedefs/errno.h.html>
"Their values shall be unique except as noted below."
(And there is no exception for ENOTSUP/EOPNOTSUP yet.)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Linux should define ENOTSUP

[Theodore Tso]

On Thu, Dec 07, 2006 at 02:59:48PM +0100, Andreas Schwab wrote:
> Theodore Tso <tytso@mit.edu> writes:
> 
> > Can you please quote chapter and verse (in POSIX) where it states that
> > ENOTSUP and EOPNOTSUP have to be numerically distinct?
> 
> <http://www.opengroup.org/onlinepubs/009695399/basedefs/errno.h.html>
> "Their values shall be unique except as noted below."
> (And there is no exception for ENOTSUP/EOPNOTSUP yet.)

Ah, but you're quoting from SuS, not POSIX.  (Yes, I'm splitting
hairs, but that's what standards are all about.  :-)

						- Ted

Re: Linux should define ENOTSUP

[Andreas Schwab]

Theodore Tso <tytso@mit.edu> writes:

> On Thu, Dec 07, 2006 at 02:59:48PM +0100, Andreas Schwab wrote:
>> Theodore Tso <tytso@mit.edu> writes:
>> 
>> > Can you please quote chapter and verse (in POSIX) where it states that
>> > ENOTSUP and EOPNOTSUP have to be numerically distinct?
>> 
>> <http://www.opengroup.org/onlinepubs/009695399/basedefs/errno.h.html>
>> "Their values shall be unique except as noted below."
>> (And there is no exception for ENOTSUP/EOPNOTSUP yet.)
>
> Ah, but you're quoting from SuS, not POSIX.  (Yes, I'm splitting
> hairs, but that's what standards are all about.  :-)

The quoted sentence is not shaded as an XSI extension, thus it is part of
POSIX-1:2001.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Linux should define ENOTSUP

[Ulrich Drepper]

On 12/7/06, Andreas Schwab <schwab@suse.de> wrote:
> The quoted sentence is not shaded as an XSI extension, thus it is part of
> POSIX-1:2001.

Perhaps I didn't make myself clear.  The change I pointed at was
accepted to the interpretations track which means that if we would
create a Technical Corrigendum 3 for the 2001 standard (which we are
not) the relaxation for the error values would be added.  The current
situation is just as good, it's just as binding.  There is no need to
reissue the standard to make such changes.

So, put this issue to rest.  There is not issue.  The whole premise
for the original post is wrong these days.  There is no compliance
problem.