All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] hcid patch
Date: Mon, 03 Oct 2005 23:02:57 +0200	[thread overview]
Message-ID: <1128373377.8472.44.camel@blade> (raw)
In-Reply-To: <e1effdeb051003070847e0d7ac@mail.gmail.com>

Hi Claudio,

> I kept some log information, if you want remove it I can send another
> patch. The error code definition was included. I am using "hciX" in
> the path name until we receive a answer from dbus list. Services under
> the path /org/bluez/Devices weren't implemented yet.
> 
> Is there other changes in this patch?

this thing looks quite good, but now we need to clean up some other
parts of your constants and function naming. And please try to keep the
BlueZ/kernel coding style.

The overall BLUEZ_DBUS prefix looks like a good idea at the beginning,
but I think we don't need it at all. So this should be enough:

#define DEVICE_PATH		"/org/bluez/Device"
#define DEVICE_INTERFACE	"org.bluez.Device"

#define MANAGER_PATH		"/org/bluez/Manager"
#define MANAGER_INTERFACE	"org.bluez.Manager"

Please also stop to shortcut some names. For example DFT for DEFAULT.
Simple write the full name, because then it is easy to read this code.

The other thing is that I don't like the difference between *_REQ and
*_SIG in the names/constants. Please don't use them.

Also please don't include any RFCOMM, PAN, HID etc. related things,
because they are not important right now and they make my life of
merging the initial step into better D-Bus a lot harder.

For the error part we will use org.bluez.Error and not EFailed or
anything like this. Since all the error stuff is currently not used, I
don't think it is a good idea to add it to the initial patch. Looking at
HAL the use of org.bluez.NoSuchDevice, etc. seems to make sense, too.

Do we really need that service_table_t thingy now? I think we should
start without it.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2005-10-03 21:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-30 18:22 [Bluez-devel] hcid patch Claudio Takahasi
2005-10-01  9:49 ` Marcel Holtmann
2005-10-03 14:08   ` Claudio Takahasi
2005-10-03 21:02     ` Marcel Holtmann [this message]
2005-10-04 12:33       ` Claudio Takahasi
2005-10-04 12:47         ` Claudio Takahasi
2005-10-04 13:11           ` Johan Hedberg
2005-10-04 13:31             ` Claudio Takahasi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1128373377.8472.44.camel@blade \
    --to=marcel@holtmann.org \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.