Subject: Re: fixing send(2) semantics (kern/29750)
To: Martin Husemann <martin@duskware.de>
From: Emmanuel Dreyfus <manu@netbsd.org>
List: tech-kern
Date: 03/26/2005 12:21:22
Martin Husemann <martin@duskware.de> wrote:

> > - There is no way of telling if the socket has blocking I/O or not. In
> > order to address this, we'd need a reference to the socket. The network
> > layer output function has the reference, so we just need to change the
> > link layer output function interface so that the socket reference gets
> > propagated there.=20
>=20
> I'm not sure I parse this correctly. If you mean "add a flag to the link
> layer output functions telling it to sleep or not" I'm fine with this
> change - I would then modify pppoe to always pass TRUE there. I would
> not like to tunnel a socket pointer all the way through the PPP code
> to ether_output.

We would need to always propagate to the link layer the information
whether we are allowed to sleep or not, regardless of what protocols are
used in the network stack. The only situation where we would always set
a non sleep is when there is no sending socket (eg: packet forwarding).

If I use blocking I/O with send(2) and a PPPoE connectivity, send(2)
have to sleep when the interface queue gets full.

I don't have an opinion on whether we need to pass a (struct socket *)
or a sleep flag, but how is it easier to tunnel the sleep flag than the
(struct socket *)?=20

--=20
Emmanuel Dreyfus
Publicit=E9 subliminale: achetez ce livre!
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org