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

From: Bill Fenner <[email-masked]>
Date: Sun, 12 Jan 2003 14:07:45 -0800

>    After exchanging a few emails with Linux kernel maintainters for network
>code, I realised that they too preferred getsockopt & setsockopt for full-
>state API over ioctls.

This is a Linux implementation detail.  The implementation of getsockopt()
in BSD 4.4 and earlier did not pass the user data to the protocol layer,
so the only information the protocol layer can be guaranteed to have
is the optname (e.g. IP_ADD_MEMBERSHIP).  Thus, a portable API cannot
assume that the data in the buffer the user passed to getsockopt() is
available to the protocol.

We considered using setsockopt() for setting the full-state, and ioctl()
for retrieving the full-state, but decided that it would be better to
have a consistent set/get API.  Since getsockopt()'s limitations required
us to use ioctl() for get, we use ioctl() for set too.

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

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 12 Jan 2003 14:28:53 -0800

It would of course be nice to have this reasoning at least in an
appendix of the MSFAPI draft so that future generations are still
aware of the reason for the compromises taken - helps especially those
folks who in a couple of years want to revise the decisions.

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Sun, 12 Jan 2003 14:28:53 -0800

Cheers
	Toerless

---

From: Bill Fenner <[email-masked]>
Date: Sun, 12 Jan 2003 23:28:52 -0800

>Would it be that hard to add that passing down to the BSD code ?

Not per se, e.g. FreeBSD since 3.0 has had access to the data
that is in the user buffer in the getsockopt code path.

The question is really e.g. Solaris, HP/UX, AIX, Windows, etc.
The original getsockopt definition does not require that the driver
have access to the data in the user buffer, so we can not define
a portable API that requires that.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Sun, 12 Jan 2003 23:28:52 -0800

Bill

---

From: Bill Fenner <[email-masked]>
Date: Sun, 12 Jan 2003 23:32:01 -0800

>BSD 4.4 could be changed to do this, it is not a limitation
>of the API the user can actually make use of.

Agile open-source systems are not our only target.  We also want this API
to work on systems on which the getsockopt() kernel implementation and
the multicast functions might be done in different groups on different
continents.  It's a lower barrier to not have to change the getsockopt()
implementation, so in our opinion it was worth the ioctl() ugliness.

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Sun, 12 Jan 2003 23:32:01 -0800

Bill

---

From: Andi Kleen <[email-masked]>
Date: Mon, 13 Jan 2003 08:16:26 +0100

Linux could support both ioctls and setsockopt, but using setsockopt
would certainly seem more elegant.

-Andi

---

From: "David S. Miller" <[email-masked]>
Date: Sun, 12 Jan 2003 23:08:48 -0800 (PST)

---

From: Andi Kleen <[email-masked]>
Date: Mon, 13 Jan 2003 08:16:26 +0100

-Andi

---

From: "David S. Miller" <[email-masked]>
Date: Sun, 12 Jan 2003 23:08:48 -0800 (PST)

---

From: "David S. Miller" <[email-masked]>
Date: Sun, 12 Jan 2003 23:36:13 -0800 (PST)

From: Bill Fenner <[email-masked]>
   Date: Sun, 12 Jan 2003 23:28:52 -0800

Those other OS's can easily be changed as well.

If the IGMP3 socket option API requires the getsockopt
to get at the user data, then people will make their
system do it.

I think this discussion is rediculious.  Things change, times
change, and it's not like the user side of the API prevents passing
the data in.

---

From: "David S. Miller" <[email-masked]>
Date: Sun, 12 Jan 2003 23:36:31 -0800 (PST)

From: Bill Fenner <[email-masked]>
   Date: Sun, 12 Jan 2003 23:32:01 -0800
   
   Agile open-source systems are not our only target.

We never suggested that, proprietary OS's can change too.
_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: "David S. Miller" <[email-masked]>
Date: Sun, 12 Jan 2003 23:36:13 -0800 (PST)

---

From: Bill Fenner <[email-masked]>
Date: Sun, 12 Jan 2003 23:57:43 -0800

>Those other OS's can easily be changed as well.

The diffs for FreeBSD were +1107 -1025 lines.  This is not something to
just shrug off and call a trivial change.  It is trivial given some
initial designs, and non-trivial given others.

>I think this discussion is rediculious.

I agree.  I think it should be obvious that the lower barrier of the
ioctl method is more important than the cleanliness of the getsockopt
method.  More importantly, that was the conclusion at the Adelaide
IDMR meeting.

Do other WG participants have opinions on this issue?

  Bill

---

From: Bill Fenner <[email-masked]>
Date: Sun, 12 Jan 2003 23:57:43 -0800

Bill

---

From: "David S. Miller" <[email-masked]>
Date: Sun, 12 Jan 2003 23:55:19 -0800 (PST)

From: Bill Fenner <[email-masked]>
   Date: Sun, 12 Jan 2003 23:57:43 -0800

   
I mean this from another perspective.

Imagine if we didn't know of any proprietary OS's that didn't pass
the user buffer down to getsockopt in the "drivers" and we specified
the IGMP3 socket options.

Then let's suppose there was such an OS that didn't pass the buffer
down.  Do you think for one second that they would complain to the
IETF instead of just fixing their code to pass the buffer down or
find some other way around the problem?

And the change doesn't require even breaking drivers, you can retain
a "getsockopt" pointer in your socket ops and make a new
"getsockopt_new" that passes the user buffer down.  getsockopt_new
if non_NULL is used in lieu of the compatability getsockopt.

Therefore I declare that there is no sensible argument against the
socket option IGMP3 controler.  In fact, I'd say ioctl() is the worst
way to do it since ioctl is arguably the worst UNIX API :)  People
tend to select it way too fast, usually because doing it right with
another API requires some effort.

So like I said, this discussion is rediculious.
_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: "David S. Miller" <[email-masked]>
Date: Sun, 12 Jan 2003 23:55:19 -0800 (PST)

---

From: "David S. Miller" <[email-masked]>
Date: Sun, 12 Jan 2003 23:36:31 -0800 (PST)

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 15 Jan 2003 23:27:40 +0100 (CET)

> a portable API that requires that.

In terms of Solaris it does not pass down the content of the getsockopt
buffer to the protocol. Furthermore, changing the system to do this
would be a lot of work. While Solaris doesn't have the ctloutput issue
that is present in BSD, it has other issues relating to the fact that
getsockopt and setsockopt are implemented using TPI option management messages.
 So while adding a new socket option following the current conventions is
trivial, changing the conventions is non-trivial.

But perhaps it is time to define an API that is expressed in terms of
a set of (library) function calls where the actual kernel interface
can be hidden under those functions, instead of doing more get/set sockopt
or ioctls.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 15 Jan 2003 23:27:40 +0100 (CET)

Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Jan 2003 07:41:16 +0100 (CET)

> All of this thread is a bunch of "it's too hard I don't want to do
> it."  Nothing more.

No. The thread is about providing an API that gets the job done
and that can be easily implemented in different platforms so that
the API can be relatively quickly available.

Is there a technical reason why it would be hard to implement 
an ioctl scheme in Linux?

Is there a technical reason why it would be hard to implement
a library interface (which might use setsockopt or whatever underneath)
in Linux?

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 16 Jan 2003 07:41:16 +0100 (CET)

Erik

---

From: Andi Kleen <[email-masked]>
Date: Thu, 16 Jan 2003 11:31:08 +0100

> a library interface (which might use setsockopt or whatever underneath)

Library interface would be relatively inconvenient for Linux, because
the only obvious place to put it would be glibc. Updating glibc is 
rather disruptive, much more so than a kernel update because the 
libc<->application interface isn't as stable as the libc<->kernel interface.
A lot of systems run with relatively old glibcs and the version state varies
wildly between distributions. In short it would be hard to deploy.

Just adding an ioctl or setsockopt is easier, because in the worst
case the application can just define the value of it in some private
header if the system includes do not provide it. Also it can be 
easily tested for at runtime unlike a library interface.

-Andi

---

From: Andi Kleen <[email-masked]>
Date: Thu, 16 Jan 2003 11:31:08 +0100

-Andi

---

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

From: Erik Nordmark <[email-masked]>
   Date: Wed, 15 Jan 2003 23:27:40 +0100 (CET)

   would be a lot of work.

I don't know how relevant this is, Solaris changes don't even occur to
fix serious security flaws from time to time.  And this is done for
the sake of 3rd party modules.

---

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

---

From: [email-masked]
Date: Thu, 16 Jan 2003 08:31:08 -0800 (PST)

David,

The IETF has a long history of consensus and interoperability, and
that is culture here as well.  The internet would not exist was it not
for this level of co-operation.  Consensus, by definition means
comprimising at times.  Just imagine if big router vendors did the
same thing 8->

Keep in mind alot of people here have to develop software that run on
these various platforms, were consistency is beautiful.

- rusty

---

From: [email-masked]
Date: Thu, 16 Jan 2003 08:31:08 -0800 (PST)

David,

- rusty

---

From: Thomas Narten <[email-masked]>
Date: Fri, 24 Jan 2003 13:41:17 -0500

Here is what an AIX developer says about this issue:

> getsockopt in AIX does not pass the getsockopt buffer contents to the
> protocol either. It looks like this would be much easier for us to
> implement with ioctls.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 24 Jan 2003 13:41:17 -0500

Thomas