Subject: Re: [magma] Re: getsockopt for full-state source filter API

From: Bill Fenner <[email-masked]>
Date: Mon, 13 Jan 2003 08:22:36 -0800

>After looking at BSD kernel code, it appears that BSD issue boils down to
>BSD kernel doing a copyin() on the getsockopt optval pointer to user data.

No, that's the easy part.  The issue is changing the calling conventions
of the pr_ctloutput() routines, that's why the change in FreeBSD was over
1000 lines.  And the real issue is not BSD per se, other than that's
where the socket interface came from.

Multicast has enough deployment problems, without adding an additional
barrier to developing the API.  I still think that you and David are
ignoring the possibility that the developer that is writing the IGMPv3
API would not have permission to modify the getsockopt handler, and
that e.g. a design committee would have to approve changes to how
getsockopt works and that multicast isn't a good enough reason.

I'll say again: we evaluated these tradeoffs already, and decided against
specifying that getsockopt has to change.  I don't think that anything
has changed to change the balance of that decision.  You want to barf when
you see that we use ioctl()?  We're in the same boat, I want to barf too,
but I still think it's the right tradeoff.

  Bill
_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Pekka Savola <[email-masked]>
Date: Mon, 13 Jan 2003 21:21:01 +0200 (EET)

Hello,

On Mon, 13 Jan 2003, Bill Fenner wrote:
[...]
> barrier to developing the API.  [...]

Of course, this goes the other way too: multicast has enough deployment
problems already without an additional need to use complex API's.  (Not as
big a point of course, but still..)

> but I still think it's the right tradeoff.

I'm a bit skeptic about the justifications, but I'd like to see one 
particular data point.

Which OS's are such that getsockopt would actually need (major) changing?
Something specific, please.  I'd like to get a picture whether it's
"almost all" or "those that pretty much nobody even cares for anymore, but
are still used there and there".

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Mon, 13 Jan 2003 21:21:01 +0200 (EET)

Hello,

---

From: "David S. Miller" <[email-masked]>
Date: Mon, 13 Jan 2003 22:07:14 -0800 (PST)

From: Bill Fenner <[email-masked]>
   Date: Mon, 13 Jan 2003 08:22:36 -0800

I totally disagree, therefore...

I think we'll have only the getsockopt() interface available under
Linux and not the ioctl(), and I bet the BSD's will follow suit in at
least making the getsockopt() method at least available.  Then we'll
see what application programmers end up preferring to use.

The result should be interesting :-)
_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: "David S. Miller" <[email-masked]>
Date: Mon, 13 Jan 2003 22:07:14 -0800 (PST)

---

From: Pavlin Radoslavov <[email-masked]>
Date: Tue, 14 Jan 2003 09:24:59 -0800

> see what application programmers end up preferring to use.

Speaking from the position of someone who has done recently
some network-related coding that is suppose to work on *BSD and
Linux, I think that developers would end-up with writing code like:

#ifdef Linux
    getsockopt(...);
#endif
#ifdef BSD
    ioctl(...);
#endif

The least-preferable solution of all.

> The result should be interesting :-)

I don't think developers will be interested in being used as guinea
pigs...

Pavlin

---

From: Pavlin Radoslavov <[email-masked]>
Date: Tue, 14 Jan 2003 09:24:59 -0800

#ifdef Linux
    getsockopt(...);
#endif
#ifdef BSD
    ioctl(...);
#endif

Pavlin

---

From: "David S. Miller" <[email-masked]>
Date: Wed, 15 Jan 2003 11:10:15 -0800 (PST)

From: Pavlin Radoslavov <[email-masked]>
   Date: Tue, 14 Jan 2003 09:24:59 -0800

I'm merely making the point that this IETF group in no way
controls what API will actually end up being used, so if they
make what is in my opinion a silly decision I can decide not
to follow their standard.

And that is what I intend to do if the broken ioctl stuff is choosen.

This group is standardizing based upon implementation details, that is
not what they should be doing.  They should instead choose the API
that makes the most sense from a programming and semantic standpoint.
_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: "David S. Miller" <[email-masked]>
Date: Wed, 15 Jan 2003 11:10:15 -0800 (PST)