Source-Changes archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



On Tue, Feb 26, 2008 at 10:01:40AM +0100, Christoph Badura wrote:
> 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.

You are ascribing to me an interpretation that I do not have.

> 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.

I do find it useful to distinguish the error conditions.

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

I must not have found the documentation in intro(2) when I looked for
it, or else I had a different interpretation.  It is an easy mistake
to make.  I see that your interpretation is what intro(2) intends, now.
Thanks for the information.

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

Thanks for the information again.  You could not have been more concise
and germane.

Dave

-- 
David Young             OJC Technologies
dyoung%ojctech.com@localhost      Urbana, IL * (217) 278-3933 ext 24


Home | Main Index | Thread Index | Old Index