Return-Path: Message-ID: From: Claudio Takahasi To: bluez-devel@lists.sourceforge.net Subject: Re: [Bluez-devel] [D-BUS PATCH] Authentication In-Reply-To: <1129986496.11428.36.camel@blade> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5812_7493715.1130159182986" References: <1129986496.11428.36.camel@blade> Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net Reply-To: bluez-devel@lists.sourceforge.net List-Unsubscribe: , List-Id: BlueZ development List-Post: List-Help: List-Subscribe: , List-Archive: Date: Mon, 24 Oct 2005 11:06:22 -0200 ------=_Part_5812_7493715.1130159182986 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Marcel, I will send a cleanup patch before send the authentication improvements patch. Regarding the variable name, It should be better change to "dd" instead of sock or sk. If you see the hcitool code standard you will notice that. I noticed that there is a HCI raw socket created in the main.c file that belongs to hcid structure. Can I use it in the functions handle_display_conn_req and handle_get_devices_req instead of create a new one? I will try apply you other suggestions. Another point is the reply method for authentication. We need discuss how w= e should design it. I am not a hcid expert therefore I would like ask you how we should implement the authentication stuff. Currently, the METHOD REPLY of the authentication doesn't consider the authentication complete event. In order to check it and reply after the authentication finishes it is required store some D-Bus message attributes(sender, serial, destination, ...). Another approach is send a SIGNAL. Which approach do you prefer send send a peer message(method reply) or a signal? Regarding the pin helper. Are you planning support the "normal" helper and the dbus helper? I am asking this because the call_pin_helper function is blocking. If you are planning support both, we have to try add the pin helper file descriptor inside the hcid main loop. Regards, Claudio. On 10/22/05, Marcel Holtmann wrote: > > Hi Claudio, > > > This is the initial patch to support authentication. There are > > improving points > > that I am planning send soon if everybody agree with my proposal. > > I applied the patch, but please do the coding style right. It seems that > you still copy some parts for your old patches. > > if (sock > 0) > close (sock); > > I first prefer to use "sk" instead of "sock", but this hasn't been used > in full consistency and so I didn't corrected it. However you need to > check for (sock >=3D 0) in case of a socket or file descriptor and we > don't put a space between the function name and its parameters. So it > must be called "close(sock);" in any case. > > It is also better to introduce more error labels than using another if > statement to check for state of a file descriptor. We now if the file > descriptor is valid or not. > > Regards > > Marcel > > > -- --------------------------------------------------------- Claudio Takahasi Nokia's Institute of Technology - INdT claudio.takahasi@indt.org.br ------=_Part_5812_7493715.1130159182986 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Marcel,

I will send a cleanup patch before send the authentication improvements pat= ch.
Regarding the variable name, It should be better change to "dd" i= nstead of
sock or sk. If you see the hcitool code standard you will notice that.

I noticed that there is a HCI raw socket created in the main.c file that be= longs to hcid structure.
Can I use it in the functions handle_display_conn_req and handle_get_device= s_req instead of create
a new one?

I will try apply you other suggestions.

Another point is the reply method for authentication. We need discuss how w= e should design it.
I am not a hcid expert therefore I would like ask you how we should impleme= nt the authentication stuff.

Currently, the METHOD REPLY of the authentication doesn't consider the auth= entication complete event.
In order to check it and reply after the auth= entication finishes it is required store some D-Bus message
attributes(sender, serial, destination, ...). Another approach is send a SI= GNAL. Which approach do you prefer
send send a peer message(method reply) or a signal?

Regarding the pin helper. Are you planning support the "normal" h= elper and the dbus helper? I am asking
this because the call_pin_helper function is blocking. If you are planning = support both, we have to try add
the pin helper file descriptor inside the hcid main loop.

Regards,
Claudio.

On 10/22/05, Marcel Holtmann <marcel@= holtmann.org> wrote:

Hi Claudio,

> This is the initial patch to support authentication= . There are
> improving points
> that I am planning send soon i= f everybody agree with my proposal.

I applied the patch, but please = do the coding style right. It seems that
you still copy some parts for your old patches.

&nbs= p; if (sock > 0)
= ; cl= ose (sock);

I first prefer to use "sk" instead of "so= ck", but this hasn't been used
in full consistency and so I didn't = corrected it. However you need to
check for (sock >=3D 0) in case of a socket or file descriptor and w= e
don't put a space between the function name and its parameters. So it<= br>must be called "close(sock);" in any case.

It is also b= etter to introduce more error labels than using another if
statement to check for state of a file descriptor. We now if the filedescriptor is valid or not.

Regards

Marcel

--
----------------------------= -----------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
claudio.takahasi@indt.org.br ------=_Part_5812_7493715.1130159182986-- ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel