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