Re: CVS commit: src/sys/dev/ic/dp8390.c

[Christoph Badura <bad%bsd.de@localhost>]

On Sun, Feb 24, 2008 at 06:20:05PM -0600, David Young wrote:
> I think that it depends.  According to my interpretation, we should
> return ENOTTY if an ioctl is not supported by this ethernet or any other
> ethernet, and ENODEV if this particular ethernet does not support the
> ioctl, but some ethernet may.  I.e., if I call DIOCGPART on an ethernet,
> then ENOTTY.  If I call SIOCSIFMTU on an ethernet that does not support
> it, then ENODEV.  Make sense?

No, that doesn't make sense at all.  The rules are unambiguous: if you
receive an ioctl code that you can't handle you return ENOTTY.  Telling
the invoking process in userland, "I'm sorry I know it is really important
that you want to perform this *specific* operation on this *particular*
device, but I can't do that right now.  Maybe you have better luck with a
different device", isn't useful.  Taking your example, you can't meaningfully
substitute a different network device for the one that you need to change
the MTU on.  And if you don't care about the particular device but only
about successfully completing the operation, the answer "sorry, maybe
someone else can handle that" isn't useful either.

The specification of ENODEV and ENOTTY in intro(2) is unambiguous, too.
And doesn't allow room for your interpretation.

Taking random samples of random (and randomly wrong) code and drawing
conclusions from false premises doesn't lead to convincing arguments.
--chris