Vivek S wrote:
> Exactly.... having to use ioctls can lead to problems if the ioctls
> change (ioctls are driver specific and the driver code can change).

That sounds like a bit of confusion to me.

ioctl(2) itself is just a mechanism.  The individual ioctls themselves
can be private (undocumented), unstable/driver-specific (as you
suggest), or stable.

The ioctls involved in interface configuration are *HIGHLY* stable.
They're the BSD-derived interfaces that have been unchanged in more than
a couple of decades.

No, they're not perfect, and, yes, there are new things added to them
and edge cases to be aware of, but the idea that ioctls are somehow more
subject to change than function calls is simply *FALSE*.

Saying that ioctl is subject to change is like saying read(2) is subject
to change because every file is different.  It's only modestly true, and
then only if you don't recognize that some files themselves have defined
contents.

> But
> if we have an API like "x = create_interface("foo0")" the backend no
> matter how complex is hidden from the user and he can be sure that the
> interface wont change even if the backend changes. This is good for both
> the user of the interface and the developers of the interface (who can
> change the backend easily knowing that it wont affect the public interface).

It's a different type of interface, to be sure, but only documentation
can determine just how stable an interface is -- no matter how it may be
implemented.

> In my personal opinion exposing an interface is the best an OS can do
> (as against ioctls or using system utilities). I may be wrong :-)

You're welcome to the opinion, but I don't think it has anything to do
with interface stability, or determining what things you can rely on.

There are deeper issues here.  If the OpenSolaris community does in fact
do away with the need for applications that know about plumbing by
making it all automatic (as the NWAM team has prototyped, and as it
seems we're driving towards), then what benefit do we get by having
function call wrappers over a non-existent feature?

Why make easy what we wish nobody needed to do, and what we expect to
make obsolete?

-- 
James Carlson         42.703N 71.076W         <[email protected]>
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to