James Carlson wrote:
> Sowmini.Varadhan at Sun.COM writes:
>
>> Moreover, looks like valp has to be null because of the immediately preceding
>> lines:
>>
>
> Actually, that's not true.
>
> After going through that while-loop, valp points to the *next*
> character after the zero (NUL) byte. That's because of the use of
> post-increment in the while condition.
>
> So, this code:
>
>
>> 96 if (!*valp || valp >= (char *)mp1->b_wptr)
>>
>> 97 valp = NULL;
>>
>>
>
> Is assuming that either you have this in the buffer:
>
> name\0\0
>
> or you have this:
>
> name\0buflen\0
>
> Yes, that double-terminated string has always been required for
> ND_GET. It's weird.
>
>
>> Does anyone have any history about this code (which seems to have
>> been around for a very long time) and esp. the "backward
>> compatibility" reference in the comment? Is there some application
>> out there that sends the ND ioctl directly, and is relying on the "hack"
>> code?
>>
>
> It dates to the 1.1 version of the code and the original Mentat
> design. It looks like the theory is that you could (somehow) have a
> return buffer that's bigger than the input buffer. That doesn't
> happen with I_STR, but perhaps they had something else in mind. (I
> think they were just upset with the inefficiency of doing a copyin on
> a huge buffer where all that's actually needed is the name and return
> length.)
>
> I think it might be time for this to go.
>
The ndd ioctl API is horribly obtuse. I spent some time reverse
engineering it at one point. I have an alternate implementation in my
own drivers. It probably is no better, because, as I said, the whole
thing is obtuse.
Unfortunately, lots of code is still using these ioctls, so we can't get
rid of them. (For example, SunVTS uses ndd ioctls directly.)
-- Garrett
