Hi Remi,
You have mentioned in the
"a015f6f: Phonet: kill the ST-Ericsson pipe controller Kconfig",
that "Support for manually enabling the pipe flow is removed as it
did not work properly, does not fit well with the socket API, and
I am not aware of any use at the moment.."
On STE U8500 modem, you must first create pipe in disabled state, then do
local link configuration (does't work when pipe is enabled) & then enable pipe.
Because of this connect() cannot be used anymore and it needs to be modified to
reintroduce pipe-controller functionality again.
Do you have any suggestions?
Regards,
Hemant Ramdasi
Le Mercredi 12 Octobre 2011 09:25:01 ext Hemant-vilas RAMDASI a écrit :
You have mentioned in the
"a015f6f: Phonet: kill the ST-Ericsson pipe controller Kconfig",
that "Support for manually enabling the pipe flow is removed as it
did not work properly, does not fit well with the socket API, and
I am not aware of any use at the moment.."
On STE U8500 modem, you must first create pipe in disabled state, then do
local link configuration (does't work when pipe is enabled) & then enable
pipe.
The Kconfig option broke support for existing hardware (Nokia N900 as a USB
gadget) and userspace (namely the oFono ISI driver). We cannot expect
distributions to provide two different kernel builds for different flavors of ISI
modems.
Because of this connect() cannot be used anymore and it needs to be modified
to reintroduce pipe-controller functionality again.
As far as I can tell, that code NEVER worked properly. Not only the use of a
build-time option is inappropriate, but the code did not deal with a number of
new corner cases that it introduced.
Do you have any suggestions?
I'm sorry but I don't really get where you're trying to get. The code had more
bugs than I could fix by myself, especially when I don't have the hardware and
the specification.
--
Rémi Denis-Courmont
http://www.remlab.net/
-----Original Message-----
From: Rémi Denis-Courmont [mailto:remi.denis-courmont@nokia.com]
Sent: Wednesday, October 12, 2011 1:28 PM
To: Hemant-vilas RAMDASI
Cc: Srinidhi KASAGAR; netdev@vger.kernel.org
Subject: Re: about phonet pipe controller
Le Mercredi 12 Octobre 2011 09:25:01 ext Hemant-vilas RAMDASI a écrit :
quoted
You have mentioned in the
"a015f6f: Phonet: kill the ST-Ericsson pipe controller Kconfig",
that "Support for manually enabling the pipe flow is removed as it
did not work properly, does not fit well with the socket API, and
I am not aware of any use at the moment.."
On STE U8500 modem, you must first create pipe in disabled state,
then do
quoted
local link configuration (does't work when pipe is enabled) & then
enable
quoted
pipe.
The Kconfig option broke support for existing hardware (Nokia N900 as a
USB
gadget) and userspace (namely the oFono ISI driver). We cannot expect
distributions to provide two different kernel builds for different
flavors of ISI
modems.
quoted
Because of this connect() cannot be used anymore and it needs to be
modified
quoted
to reintroduce pipe-controller functionality again.
As far as I can tell, that code NEVER worked properly. Not only the use
of a
build-time option is inappropriate, but the code did not deal with a
number of
new corner cases that it introduced.
Yes, I agree that build-time option is not required..But what are those corner cases?
quoted
Do you have any suggestions?
I'm sorry but I don't really get where you're trying to get. The code
had more
bugs than I could fix by myself, especially when I don't have the
hardware and
the specification.
As far as I know, connect() API was not there initially. It was implemented as part
of pipe-controller after your feedback.
We would like to modify connect to create pipe in disabled mode and enable it in
setsockopt call.
Basically the problem with current implementation is that there is no way today for
anyone to disable/enable pipe.
Regards,
Hemant
Le Mercredi 12 Octobre 2011 12:58:08 ext Hemant-vilas RAMDASI a écrit :
Yes, I agree that build-time option is not required..But what are those
corner cases?
This is old stuff. I don't remember the details, nor did I investigate the
whole thing. But the code seemed to assume that userspace are fully trusted,
the remote Phonet nodes also. That does not work.
Protocol-level race conditions, API level race conditions, crashed remote
peers, crashing user space processes, invalid API use, etc. All that needs to
be dealt with safely. This is kernel code!
--
Rémi Denis-Courmont
http://www.remlab.net/