* [PATCH] virt: Revert only update macaddr cache when capture dhcp ACK pkt
From: Lucas Meneghel Rodrigues @ 2011-10-24 16:54 UTC (permalink / raw)
To: autotest; +Cc: kvm
Revert commit d9bab5bef598b4b415d004eb62e9cd32c3243565, that changes
how the macaddr cache is updated. This patch brought a lot of
regressions on our internal tests, so it'll be dropped until a possibly
safer version of the fix is proposed.
Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
---
client/virt/virt_env_process.py | 10 ++--------
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/client/virt/virt_env_process.py b/client/virt/virt_env_process.py
index a1ec07a..25285b8 100644
--- a/client/virt/virt_env_process.py
+++ b/client/virt/virt_env_process.py
@@ -403,20 +403,14 @@ def _update_address_cache(address_cache, line):
address_cache["last_seen"] = matches[0]
if re.search("Client.Ethernet.Address", line, re.IGNORECASE):
matches = re.findall(r"\w*:\w*:\w*:\w*:\w*:\w*", line)
- if matches:
- address_cache["last_mac"] = matches[0]
- if re.search("DHCP-Message", line, re.IGNORECASE):
- matches = re.findall(r"ACK", line)
- if matches and (address_cache.get("last_seen") and
- address_cache.get("last_mac")):
- mac_address = address_cache.get("last_mac").lower()
+ if matches and address_cache.get("last_seen"):
+ mac_address = matches[0].lower()
if time.time() - address_cache.get("time_%s" % mac_address, 0) > 5:
logging.debug("(address cache) Adding cache entry: %s ---> %s",
mac_address, address_cache.get("last_seen"))
address_cache[mac_address] = address_cache.get("last_seen")
address_cache["time_%s" % mac_address] = time.time()
del address_cache["last_seen"]
- del address_cache["last_mac"]
def _take_screendumps(test, params, env):
--
1.7.7
^ permalink raw reply related
* Re: xfs_repair v3.1.6 - Segmentation fault AND XFS internal error xfs_btree_check_sblock
From: Michael Monnerie @ 2011-10-24 16:55 UTC (permalink / raw)
To: xfs; +Cc: Richard Ems
In-Reply-To: <4E9D4DE3.5080304@cape-horn-eng.com>
[-- Attachment #1.1: Type: Text/Plain, Size: 838 bytes --]
On Dienstag, 18. Oktober 2011 Richard Ems wrote:
> We had a hard disc failure on an Areca 1680 RAID controller, RAID 6.
> I checked the firmware and the last available version is already
> installed.
Did you check your disks are compatible? Areca's 1680 is pretty hard
about disks firmware, we've had bad behaviour if drive+firmware were not
in the support list.
If disks are compatible, and one broke, it could well be it behaved very
bad and wrote different things than it read back. If you rebuilt your
raid, let it check again to confirm it's good now. We've had that error
once... finally we rebuilt the whole damn raid from scratch.
--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc
it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: how to run ceph on top of other local file system
From: Tommi Virtanen @ 2011-10-24 16:55 UTC (permalink / raw)
To: sheng qiu; +Cc: ceph-devel
In-Reply-To: <CAB7xdin1rNSi6zMQcnOviu2GVwnu3iNX46qh51vSviXZquhiRA@mail.gmail.com>
On Sun, Oct 23, 2011 at 12:22, sheng qiu <herbert1984106@gmail.com> wrote:
> does ceph only support ext3 and btrfs? i mean if i have another file
> system, it support xattr, but it does not support journals, can i
> close the journal config and run it with ceph?
Ceph supports OSD storage on POSIX-compliant filesystems with extended
attributes. There are some edge cases that are still problematic, see
the email with subject "ceph on non-btrfs file systems" that Sage just
sent for a better discussion of those.
I'm not sure what you mean by a filesystem "not supporting journals",
the ceph-osd journal is just a file it writes to. I'm not sure what
you mean by "closing the journal config"; you can disable the journal,
but that will likely just make things slower; once again, using a
journal is possible on any filesystem, btrfs just makes it more
effective.
> i tried to do that by modifying the ceph.conf file (close the journal
> on osd). the mkcephfs seems ok, but when i start the service, cosd
> will crash.
> here's the log:
> *** Caught signal (Aborted) **
> in thread 0x7f1845ce6720
> ceph version 0.34 (commit:2f039eeeb745622b866d80feda7afa055e15f6d6)
> 1: ./cosd() [0x5c6304]
...
> 9: (CrushWrapper::decode(ceph::buffer::list::iterator&)+0xac) [0x5611fc]
> 10: (OSDMap::decode(ceph::buffer::list&)+0x8aa) [0x5622aa]
> 11: (OSD::get_map(unsigned int)+0x221) [0x52f441]
That sounds more like the osdmap is corrupt, somehow. Anyone else have
more specific suggestions?
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ALSA PulseAudio plugin: snd_pcm_rewindable() returns >0, but snd_pcm_rewind() is broken
From: Nikolay Nikolov @ 2011-10-24 16:55 UTC (permalink / raw)
To: alsa-devel
In-Reply-To: <4ea5858a.4a2acc0a.3bb5.5b58SMTPIN_ADDED@mx.google.com>
On 10/24/2011 06:34 PM, Pierre-Louis Bossart wrote:
> You want to avoid rewinding completely. Your audio hardware might have
> prefetched data with the DMA subsystem. Rewinding completely might result in
> an inconsistent configuration and possibly underflows. If you look at the
> PulseAudio code, we've introduced some thresholds beyond which we don't
> rewind (128 bytes or 1ms off the top of my head).
> You might argue that snd_pcm_rewindable is broken, but it's somewhat
> difficult to fix as the amount of prefetched data isn't modeled in the
> driver and it's very much hardware-specific. Using a less aggressive
> approach works fine on most hardware.
> -Pierre
Yes, I figured this out while experimenting with real hw alsa devices
and that's why I actually rewind snd_pcm_rewindable() minus some
threshold, that can be configured. However with the alsa pulseaudio
plugin, rewinding seems to be broken completely, even with a very large
threshold.
^ permalink raw reply
* Re: 2.6.38.8 kernel bug in XFS or megaraid driver with heavy I/O load
From: Michael Monnerie @ 2011-10-24 16:45 UTC (permalink / raw)
To: xfs; +Cc: jesper, Christoph Hellwig, aradford, linux-kernel
In-Reply-To: <e78a7c38af135cee4b742c99ecd1c011.squirrel@shrek.krogh.cc>
[-- Attachment #1: Type: Text/Plain, Size: 853 bytes --]
On Montag, 17. Oktober 2011 jesper@krogh.cc wrote:
> Over the weekend, we have run memtest for 4 hours (50% of the
> complete tests according to memtest) and it didnt find anything.
This is a bit OT, but you *must* run at least one full loop of memtest
in order to have significant output. I've had PCs that only broke on
test 7, and sometimes even a PC could run 2-3 loops before a bad bit was
found on the 4th loop or so. Only if there's a nasty error, like a
physically broken mainboard, you'll gets errors quickly.
Despite that, I think your problem is not memory based, as you said you
use ECC, and I'd believe you've turned on background scrubbing.
--
mit freundlichen Grüssen,
Michael Monnerie, Ing. BSc
it-management Internet Services: Protéger
http://proteger.at [gesprochen: Prot-e-schee]
Tel: +43 660 / 415 6531
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH RFC] try to create KBUILD_OUTPUT automatically
From: Valdis.Kletnieks @ 2011-10-24 16:55 UTC (permalink / raw)
To: Peter Foley; +Cc: Linux Kbuild Mailing List, Linux Kernel Mailing List, mmarek
In-Reply-To: <alpine.LNX.2.00.1110221049460.59156@linux>
[-- Attachment #1: Type: text/plain, Size: 423 bytes --]
On Sat, 22 Oct 2011 11:12:29 EDT, Peter Foley said:
> This patch makes it possible to execute make O=work instead of
> mkdir work
> make O=work
The case can be made that this is a Bad Idea, because it means you can't catch
a typo in your O= setting. This is particularly bad when it silently fails to
update the stuff in out-dir because you did a 'make O=out-diir'.
So NACK on this, if anybody cares what I think... ;)
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH] scheduler rate controller
From: Keir Fraser @ 2011-10-24 16:57 UTC (permalink / raw)
To: George Dunlap, Lv, Hui
Cc: Duan, Jiangang, Tian, Kevin, xen-devel@lists.xensource.com,
Dong, Eddie
In-Reply-To: <CAFLBxZZ9nqeb7CVqTZCsEtJRjgGMTHF2Ak929kvauj2KUFSOyg@mail.gmail.com>
On 24/10/2011 17:17, "George Dunlap" <George.Dunlap@eu.citrix.com> wrote:
> * I'm not sure I like the idea of doing this at the generic level than
> at the specific scheduler level -- e.g., inside of credit1. For
> better or for worse, all aspects of scheduling work together, and even
> small changes tend to have a significant effect on the emergent
> behavior. I understand why you'd want this in the generic scheduling
> code; but it seems like it would be better for each scheduler to
> implement a rate control independently.
Yes, this doesn't belong in schedule.c.
-- Keir
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 2/4] Add access control support to qemu bridge helper
From: Blue Swirl @ 2011-10-24 16:58 UTC (permalink / raw)
To: Corey Bryant; +Cc: rmarwah, aliguori, qemu-devel
In-Reply-To: <4EA56BCD.1070202@linux.vnet.ibm.com>
On Mon, Oct 24, 2011 at 13:44, Corey Bryant <coreyb@linux.vnet.ibm.com> wrote:
>
>
> On 10/23/2011 09:10 AM, Blue Swirl wrote:
>>
>> On Fri, Oct 21, 2011 at 15:07, Corey Bryant<coreyb@linux.vnet.ibm.com>
>> wrote:
>>>
>>> > We go to great lengths to restrict ourselves to just cap_net_admin as
>>> > an OS
>>> > enforced security mechanism. However, we further restrict what we
>>> > allow users
>>> > to do to simply adding a tap device to a bridge interface by virtue of
>>> > the fact
>>> > that this is the only functionality we expose.
>>> >
>>> > This is not good enough though. An administrator is likely to want to
>>> > restrict
>>> > the bridges that an unprivileged user can access, in particular, to
>>> > restrict
>>> > an unprivileged user from putting a guest on what should be isolated
>>> > networks.
>>> >
>>> > This patch implements an ACL mechanism that is enforced by
>>> > qemu-bridge-helper.
>>> > The ACLs are fairly simple whitelist/blacklist mechanisms with a
>>> > wildcard of
>>> > 'all'. All users are blacklisted by default, and deny takes
>>> > precedence over
>>> > allow.
>>> >
>>> > An interesting feature of this ACL mechanism is that you can include
>>> > external
>>> > ACL files. The main reason to support this is so that you can set
>>> > different
>>> > file system permissions on those external ACL files. This allows an
>>> > administrator to implement rather sophisicated ACL policies based on
>>> > user/group
>>
>> sophisticated
>>
>
> Yep, thanks.
>
>>> > policies via the file system.
>>> >
>>> > As an example:
>>> >
>>> > /etc/qemu/bridge.conf root:qemu 0640
>>> >
>>> > allow br0
>>> > include /etc/qemu/alice.conf
>>> > include /etc/qemu/bob.conf
>>> > include /etc/qemu/charlie.conf
>>> >
>>> > /etc/qemu/alice.conf root:alice 0640
>>> > allow br1
>>> >
>>> > /etc/qemu/bob.conf root:bob 0640
>>> > allow br2
>>> >
>>> > /etc/qemu/charlie.conf root:charlie 0640
>>> > deny all
>>
>> I think syntax 'include/etc/qemu/user.d/*.conf' or 'includedir
>> /etc/qemu/user.d' could be also useful.
>>
>
> That could be useful, though I'm not sure it's necessary right now.
It can be added later.
>>> > This ACL pattern allows any user in the qemu group to get a tap device
>>> > connected to br0 (which is bridged to the physical network).
>>> >
>>> > Users in the alice group can additionally get a tap device connected
>>> > to br1.
>>> > This allows br1 to act as a private bridge for the alice group.
>>> >
>>> > Users in the bob group can additionally get a tap device connected to
>>> > br2.
>>> > This allows br2 to act as a private bridge for the bob group.
>>> >
>>> > Users in the charlie group cannot get a tap device connected to any
>>> > bridge.
>>> >
>>> > Under no circumstance can the bob group get access to br1 or can the
>>> > alice
>>> > group get access to br2. And under no cicumstance can the charlie
>>> > group
>>> > get access to any bridge.
>>> >
>>> > Signed-off-by: Anthony Liguori<aliguori@us.ibm.com>
>>> > Signed-off-by: Richa Marwaha<rmarwah@linux.vnet.ibm.com>
>>> > Signed-off-by: Corey Bryant<coreyb@linux.vnet.ibm.com>
>>> > ---
>>> > qemu-bridge-helper.c | 141
>>> > ++++++++++++++++++++++++++++++++++++++++++++++++++
>>> > 1 files changed, 141 insertions(+), 0 deletions(-)
>>> >
>>> > diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
>>> > index 2ce82fb..db257d5 100644
>>> > --- a/qemu-bridge-helper.c
>>> > +++ b/qemu-bridge-helper.c
>>> > @@ -33,6 +33,105 @@
>>> >
>>> > #include "net/tap-linux.h"
>>> >
>>> > +#define MAX_ACLS (128)
>>
>> If all users (or groups) in the system have an ACL, this number could
>> be way too low. Please use a list instead.
>>
>
> I agree, we shouldn't be hard-coding the limit here. I'll update this.
>
>>> > +#define DEFAULT_ACL_FILE CONFIG_QEMU_CONFDIR "/bridge.conf"
>>> > +
>>> > +enum {
>>> > + ACL_ALLOW = 0,
>>> > + ACL_ALLOW_ALL,
>>> > + ACL_DENY,
>>> > + ACL_DENY_ALL,
>>> > +};
>>> > +
>>> > +typedef struct ACLRule {
>>> > + int type;
>>> > + char iface[IFNAMSIZ];
>>> > +} ACLRule;
>>> > +
>>> > +static int parse_acl_file(const char *filename, ACLRule *acls, int
>>> > *pacl_count)
>>> > +{
>>> > + int acl_count = *pacl_count;
>>> > + FILE *f;
>>> > + char line[4096];
>>> > +
>>> > + f = fopen(filename, "r");
>>> > + if (f == NULL) {
>>> > + return -1;
>>> > + }
>>> > +
>>> > + while (acl_count != MAX_ACLS&&
>>> > + fgets(line, sizeof(line), f) != NULL) {
>>> > + char *ptr = line;
>>> > + char *cmd, *arg, *argend;
>>> > +
>>> > + while (isspace(*ptr)) {
>>> > + ptr++;
>>> > + }
>>> > +
>>> > + /* skip comments and empty lines */
>>> > + if (*ptr == '#' || *ptr == 0) {
>>> > + continue;
>>> > + }
>>> > +
>>> > + cmd = ptr;
>>> > + arg = strchr(cmd, ' ');
>>> > + if (arg == NULL) {
>>> > + arg = strchr(cmd, '\t');
>>> > + }
>>> > +
>>> > + if (arg == NULL) {
>>> > + fprintf(stderr, "Invalid config line:\n %s\n", line);
>>> > + fclose(f);
>>> > + errno = EINVAL;
>>> > + return -1;
>>> > + }
>>> > +
>>> > + *arg = 0;
>>> > + arg++;
>>> > + while (isspace(*arg)) {
>>> > + arg++;
>>> > + }
>>> > +
>>> > + argend = arg + strlen(arg);
>>> > + while (arg != argend&& isspace(*(argend - 1))) {
>>> > + argend--;
>>> > + }
>>
>> These while loops to skip spaces are repeated, but the comment
>> skipping part is not, so it is not possible to have comments after
>> rules or split rules to several lines. I'd add a simple state variable
>> to track at which stage we are in parsing instead.
>>
>
> That could be useful too, but again not sure it's necessary right now. I
> really like the simplicity we have with the existing approach.
It's not necessary, more like cleanup _if_ it turns out to be even simpler.
>>> > + *argend = 0;
>>> > +
>>> > + if (strcmp(cmd, "deny") == 0) {
>>> > + if (strcmp(arg, "all") == 0) {
>>> > + acls[acl_count].type = ACL_DENY_ALL;
>>> > + } else {
>>> > + acls[acl_count].type = ACL_DENY;
>>> > + snprintf(acls[acl_count].iface, IFNAMSIZ, "%s", arg);
>>> > + }
>>> > + acl_count++;
>>> > + } else if (strcmp(cmd, "allow") == 0) {
>>> > + if (strcmp(arg, "all") == 0) {
>>> > + acls[acl_count].type = ACL_ALLOW_ALL;
>>> > + } else {
>>> > + acls[acl_count].type = ACL_ALLOW;
>>> > + snprintf(acls[acl_count].iface, IFNAMSIZ, "%s", arg);
>>> > + }
>>> > + acl_count++;
>>> > + } else if (strcmp(cmd, "include") == 0) {
>>> > + /* ignore errors */
>>> > + parse_acl_file(arg, acls,&acl_count);
>>> > + } else {
>>> > + fprintf(stderr, "Unknown command `%s'\n", cmd);
>>> > + fclose(f);
>>> > + errno = EINVAL;
>>> > + return -1;
>>> > + }
>>> > + }
>>> > +
>>> > + *pacl_count = acl_count;
>>> > +
>>> > + fclose(f);
>>> > +
>>> > + return 0;
>>> > +}
>>> > +
>>> > static int has_vnet_hdr(int fd)
>>> > {
>>> > unsigned int features = 0;
>>> > @@ -95,6 +194,9 @@ int main(int argc, char **argv)
>>> > const char *bridge;
>>> > char iface[IFNAMSIZ];
>>> > int index;
>>> > + ACLRule acls[MAX_ACLS];
>>> > + int acl_count = 0;
>>> > + int i, access_allowed, access_denied;
>>> >
>>> > /* parse arguments */
>>> > if (argc< 3 || argc> 4) {
>>> > @@ -115,6 +217,45 @@ int main(int argc, char **argv)
>>> > bridge = argv[index++];
>>> > unixfd = atoi(argv[index++]);
>>> >
>>> > + /* parse default acl file */
>>> > + if (parse_acl_file(DEFAULT_ACL_FILE, acls,&acl_count) == -1) {
>>> > + fprintf(stderr, "failed to parse default acl file `%s'\n",
>>> > + DEFAULT_ACL_FILE);
>>> > + return -errno;
>>> > + }
>>> > +
>>> > + /* validate bridge against acl -- default policy is to deny
>>> > + * according acl policy if we have a deny and allow both
>>> > + * then deny should always win over allow
>>> > + */
>>> > + access_allowed = 0;
>>> > + access_denied = 0;
>>> > + for (i = 0; i< acl_count; i++) {
>>> > + switch (acls[i].type) {
>>> > + case ACL_ALLOW_ALL:
>>> > + access_allowed = 1;
>>> > + break;
>>> > + case ACL_ALLOW:
>>> > + if (strcmp(bridge, acls[i].iface) == 0) {
>>> > + access_allowed = 1;
>>> > + }
>>> > + break;
>>> > + case ACL_DENY_ALL:
>>> > + access_denied = 1;
>>> > + break;
>>> > + case ACL_DENY:
>>> > + if (strcmp(bridge, acls[i].iface) == 0) {
>>> > + access_denied = 1;
>>> > + }
>>> > + break;
>>> > + }
>>> > + }
>>> > +
>>> > + if ((access_allowed == 0) || (access_denied == 1)) {
>>> > + fprintf(stderr, "access denied by acl file\n");
>>> > + return -EPERM;
>>> > + }
>>> > +
>>> > /* open a socket to use to control the network interfaces */
>>> > ctlfd = socket(AF_INET, SOCK_STREAM, 0);
>>> > if (ctlfd == -1) {
>>> > --
>>> > 1.7.3.4
>>> >
>>> >
>>> >
>
> --
> Regards,
> Corey
>
^ permalink raw reply
* [Buildroot] Some topics for the Buildroot Developer Day
From: Robert Schwebel @ 2011-10-24 16:59 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111024173815.2277c6dd@skate>
Hi Thomas,
On Mon, Oct 24, 2011 at 05:38:15PM +0200, Thomas Petazzoni wrote:
> ELCE 2011 meeting agenda
> ========================
I cannot comment much about the buildroot specific things, being an
alien here :) However, some comments for topics where we might be able
to do some collaboration with the ptxdist + buildroot folks:
> * Testing infrastructure. Possible to put build results on the Web
> server? Common format for them?
This would surely be an interesting topic. We have worked on a test
infrastructure for ptxdist for a while now; in fact, we are in the 3rd
iteration:
- The first one was "expect" based. It failed because tcl is *just* so
ugly, and the risk of getting eye cancer was simply too high ...
- The 2nd one was Python / pexpect based (failed because our method to
connect the serial port's file descriptor to pexpect was discontinued
some python minor revisions later). And it turned out that our initial
idea to easily re-use tests due to the object orientation of Python
didn't work, because the test adaptions to a scenario often are bigger
then the test itself.
- We have a kermit based infrastructure now, with shell wrappers; the
kermit code is ugly as hell, but it works reliably and is well
wrapped.
If somebody is interested, I can show how we do that.
However, we also do not have the infrastructure for a sane
representation + website presentation of test results, so this is
definitely something where we might collaborate nicely.
> * Next big directions. What are the next big directions for Buildroot
> ? The major features we want to implement ?
Does buildroot have a possibility to split between runtime and build
time dependencies? This is something we are fighting with.
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [U-Boot] My Dearest one,
From: Gift Justin @ 2011-10-24 17:01 UTC (permalink / raw)
To: u-boot
My Dearest one,
Hi, My name is Gift Justin Yak, 23years old originated from Sudan. I decide to contact you after my prayers, I really want to have a good relationship with you. My father Dr. Justin Yak was the former Minister for SPLA Affairs and Special Adviser to President Salva Kiir of South Sudan for Decentralization. My father Dr.Justin Yak and my mother including other top Military officers and top govaernment officials had been on board when the plane crashed on Friday May 02, 2008.
You can read more about the crash through the below site:
http://news.bbc.co.uk/2/hi/ africa/7380412.stm
After the burial of my father, my uncle conspired and sold my father's properties to a Chinease Expatriate and live nothing for me. On a faithful morning, I opened my father's briefcase and found out the documents which he have deposited huge amount of money in one bank in Burkina Faso with my name as the next of kin. I traveled to Burkina Faso to withdraw the money so that I can start a better life and take care of myself. On my arrival, the Branch manager of the Bank whom I met in person told me that my father's instruction to the bank was the money be release to me only when I am married or present a trustee who will help me and invest the money overseas.
I have chosen to contact you after my prayers and I believe that you will not betray my trust. But rather take me as your own sister. Though you may wonder why I am so soon revealing myself to you without knowing you, well, I will say that my mind convinced me that you are the true person to help me. More so, I will like to disclose much to you if you can help me to relocate to your country because my uncle have threaten to assassinate me. The amount is $4.5 Million and I have confirmed from the bank in Burkina Faso. You will also help me to place the money in a more profitable business venture in your Country.
However, you will help by recommending a nice University in your country so that I can complete my studies. It is my intention to compensate you with 30% of the total money for your services and the balance shall be my capital in your establishment. As soon as I receive your interest in helping me, I will put things into action immediately. In the light of the above, I shall appreciate an urgent message indicating your ability and willingness to handle this transaction sincerely. Please do keep this only to your self. I beg you not to disclose it till i come over because I am affraid of my wicked uncle who has threatened to kill me.
Sincerely yours,
Miss Gift Justin Yak
^ permalink raw reply
* Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Christoph Fritz @ 2011-10-24 17:09 UTC (permalink / raw)
To: Denilson Figueiredo de Sá
Cc: linux-kernel, Jiri Kosina, linux-input, linux-usb
In-Reply-To: <op.v3q34la3dsdv5o@localhost>
Hi Denilson,
please see my comment below.
On Sat, 2011-10-22 at 09:42 -0200, Denilson Figueiredo de Sá wrote:
> Short description:
>
> An absolute pointing device using USB HID defines a LOGICAL_MINIMUM and
> a LOGICAL_MAXIMUM for X, Y axes, and then sends a HID report containing
> values outside that range.
>
> Linux kernel should ignore values outside that range, as they are not
> meaningful.
To answer with a quote from the comment above input.h:"struct
input_absinfo":
*
* Note that input core does not clamp reported values to the
* [minimum, maximum] limits, such task is left to userspace.
*
to do so, use this from input.h:
#define EVIOCGABS(abs) _IOR('E', 0x40 + (abs), struct input_absinfo) /* get abs value/limits */
#define EVIOCSABS(abs) _IOW('E', 0xc0 + (abs), struct input_absinfo) /* set abs value/limits */
> <SNIP>
Thanks,
-- chf
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Christoph Fritz @ 2011-10-24 17:09 UTC (permalink / raw)
To: Denilson Figueiredo de Sá
Cc: linux-kernel, Jiri Kosina, linux-input, linux-usb
In-Reply-To: <op.v3q34la3dsdv5o@localhost>
Hi Denilson,
please see my comment below.
On Sat, 2011-10-22 at 09:42 -0200, Denilson Figueiredo de Sá wrote:
> Short description:
>
> An absolute pointing device using USB HID defines a LOGICAL_MINIMUM and
> a LOGICAL_MAXIMUM for X, Y axes, and then sends a HID report containing
> values outside that range.
>
> Linux kernel should ignore values outside that range, as they are not
> meaningful.
To answer with a quote from the comment above input.h:"struct
input_absinfo":
*
* Note that input core does not clamp reported values to the
* [minimum, maximum] limits, such task is left to userspace.
*
to do so, use this from input.h:
#define EVIOCGABS(abs) _IOR('E', 0x40 + (abs), struct input_absinfo) /* get abs value/limits */
#define EVIOCSABS(abs) _IOW('E', 0xc0 + (abs), struct input_absinfo) /* set abs value/limits */
> <SNIP>
Thanks,
-- chf
^ permalink raw reply
* Health Thermometer Profile
From: Santiago Carot-Nemesio @ 2011-10-24 17:04 UTC (permalink / raw)
To: linux-bluetooth
This set of patches enable applications to register watchers in order to
receive final measurements. Besides, all fixes suggested in the mailing
list have been applied.
[PATCH 1/8] Process characteristic descriptors in the thermometer
[PATCH 2/8] Get valid range descriptor if it is supported
[PATCH 3/8] Implement D-Bus register watcher function
[PATCH 4/8] Implement D-Bus unregister watcher function
[PATCH 5/8] Enable final measurement indications when first watcher
[PATCH 6/8] Disable final measurements indication when last watcher
[PATCH 7/8] Manage watcher's disconnections from the bus
[PATCH 8/8] Implement D-Bus get properties function
^ permalink raw reply
* [PATCH 1/8] Process characteristic descriptors in the thermometer service.
From: Santiago Carot-Nemesio @ 2011-10-24 17:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
In-Reply-To: <1319475848-4171-1-git-send-email-sancane@gmail.com>
---
thermometer/thermometer.c | 77 ++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 76 insertions(+), 1 deletions(-)
diff --git a/thermometer/thermometer.c b/thermometer/thermometer.c
index b4dad79..4008bb9 100644
--- a/thermometer/thermometer.c
+++ b/thermometer/thermometer.c
@@ -37,6 +37,7 @@
#define THERMOMETER_INTERFACE "org.bluez.Thermometer"
+#define TEMPERATURE_MEASUREMENT_UUID "00002a1c-0000-1000-8000-00805f9b34fb"
#define TEMPERATURE_TYPE_UUID "00002a1d-0000-1000-8000-00805f9b34fb"
#define INTERMEDIATE_TEMPERATURE_UUID "00002a1e-0000-1000-8000-00805f9b34fb"
#define MEASUREMENT_INTERVAL_UUID "00002a21-0000-1000-8000-00805f9b34fb"
@@ -156,10 +157,84 @@ static void change_property(struct thermometer *t, const gchar *name,
DBG("%s is not a thermometer property", name);
}
+static void process_thermometer_desc(struct descriptor *desc)
+{
+ struct characteristic *ch = desc->ch;
+ char uuidstr[MAX_LEN_UUID_STR];
+ bt_uuid_t btuuid;
+
+ bt_uuid16_create(&btuuid, GATT_CLIENT_CHARAC_CFG_UUID);
+
+ if (bt_uuid_cmp(&desc->uuid, &btuuid) == 0) {
+ if (g_strcmp0(ch->attr.uuid,
+ TEMPERATURE_MEASUREMENT_UUID) == 0) {
+ /* TODO: Check if we have to enable it */
+ DBG("C.C.C in Temperature Measurement");
+ } else if (g_strcmp0(ch->attr.uuid,
+ INTERMEDIATE_TEMPERATURE_UUID) == 0) {
+ /* TODO: Check if we have to enable it */
+ DBG("C.C.C in Intermediate Temperature");
+ } else if (g_strcmp0(ch->attr.uuid,
+ MEASUREMENT_INTERVAL_UUID) == 0) {
+ /* TODO: Enable indications */
+ DBG("C.C.C in Measurement Interval");
+ } else
+ goto done;
+
+ return;
+ }
+
+ bt_uuid16_create(&btuuid, GATT_CHARAC_VALID_RANGE_UUID);
+
+ if (bt_uuid_cmp(&desc->uuid, &btuuid) == 0 && g_strcmp0(ch->attr.uuid,
+ MEASUREMENT_INTERVAL_UUID) == 0) {
+ /* TODO: Process Measurement Interval */
+ return;
+ }
+
+done:
+ bt_uuid_to_string(&desc->uuid, uuidstr, MAX_LEN_UUID_STR);
+ DBG("Ignored descriptor %s in characteristic %s", uuidstr,
+ ch->attr.uuid);
+}
+
static void discover_desc_cb(guint8 status, const guint8 *pdu, guint16 len,
gpointer user_data)
{
- /* TODO */
+ struct characteristic *ch = user_data;
+ struct att_data_list *list;
+ guint8 format;
+ int i;
+
+ if (status != 0) {
+ error("Discover all characteristic descriptors failed [%s]: %s",
+ ch->attr.uuid, att_ecode2str(status));
+ return;
+ }
+
+ list = dec_find_info_resp(pdu, len, &format);
+ if (list == NULL)
+ return;
+
+ for (i = 0; i < list->num; i++) {
+ struct descriptor *desc;
+ uint8_t *value;
+
+ value = list->data[i];
+ desc = g_new0(struct descriptor, 1);
+ desc->handle = att_get_u16(value);
+ desc->ch = ch;
+
+ if (format == 0x01)
+ desc->uuid = att_get_uuid16(&value[2]);
+ else
+ desc->uuid = att_get_uuid128(&value[2]);
+
+ ch->desc = g_slist_append(ch->desc, desc);
+ process_thermometer_desc(desc);
+ }
+
+ att_data_list_free(list);
}
static void read_temp_type_cb(guint8 status, const guint8 *pdu, guint16 len,
--
1.7.6.1
^ permalink raw reply related
* [PATCH 2/8] Get valid range descriptor if it is supported
From: Santiago Carot-Nemesio @ 2011-10-24 17:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
In-Reply-To: <1319475848-4171-2-git-send-email-sancane@gmail.com>
---
thermometer/thermometer.c | 39 ++++++++++++++++++++++++++++++++++++++-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/thermometer/thermometer.c b/thermometer/thermometer.c
index 4008bb9..9c9a861 100644
--- a/thermometer/thermometer.c
+++ b/thermometer/thermometer.c
@@ -157,6 +157,42 @@ static void change_property(struct thermometer *t, const gchar *name,
DBG("%s is not a thermometer property", name);
}
+static void valid_range_desc_cb(guint8 status, const guint8 *pdu, guint16 len,
+ gpointer user_data)
+{
+ struct descriptor *desc = user_data;
+ uint8_t value[ATT_MAX_MTU];
+ uint16_t max, min;
+ int vlen;
+
+ if (status != 0) {
+ DBG("Valid Range descriptor read failed: %s",
+ att_ecode2str(status));
+ return;
+ }
+
+ if (!dec_read_resp(pdu, len, value, &vlen)) {
+ DBG("Protocol error\n");
+ return;
+ }
+
+ if (vlen < 4) {
+ DBG("Invalid range received");
+ return;
+ }
+
+ min = att_get_u16(&value[0]);
+ max = att_get_u16(&value[2]);
+
+ if (min == 0 || min > max) {
+ DBG("Invalid range");
+ return;
+ }
+
+ change_property(desc->ch->t, "Maximum", &max);
+ change_property(desc->ch->t, "Minimum", &min);
+}
+
static void process_thermometer_desc(struct descriptor *desc)
{
struct characteristic *ch = desc->ch;
@@ -188,7 +224,8 @@ static void process_thermometer_desc(struct descriptor *desc)
if (bt_uuid_cmp(&desc->uuid, &btuuid) == 0 && g_strcmp0(ch->attr.uuid,
MEASUREMENT_INTERVAL_UUID) == 0) {
- /* TODO: Process Measurement Interval */
+ gatt_read_char(ch->t->attrib, desc->handle, 0,
+ valid_range_desc_cb, desc);
return;
}
--
1.7.6.1
^ permalink raw reply related
* [PATCH 3/8] Implement D-Bus register watcher function
From: Santiago Carot-Nemesio @ 2011-10-24 17:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
In-Reply-To: <1319475848-4171-3-git-send-email-sancane@gmail.com>
---
thermometer/thermometer.c | 96 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 93 insertions(+), 3 deletions(-)
diff --git a/thermometer/thermometer.c b/thermometer/thermometer.c
index 9c9a861..155b84a 100644
--- a/thermometer/thermometer.c
+++ b/thermometer/thermometer.c
@@ -50,6 +50,7 @@ struct thermometer {
guint attioid; /* Att watcher id */
guint attindid; /* Att incications id */
GSList *chars; /* Characteristics */
+ GSList *fwatchers; /* Final measurements */
gboolean intermediate;
guint8 type;
guint16 interval;
@@ -71,8 +72,27 @@ struct descriptor {
bt_uuid_t uuid;
};
+struct watcher {
+ struct thermometer *t;
+ guint id;
+ gchar *srv;
+ gchar *path;
+};
+
static GSList *thermometers = NULL;
+static void destroy_watcher(gpointer user_data)
+{
+ struct watcher *watcher = user_data;
+
+ if (watcher->id > 0)
+ g_dbus_remove_watch(watcher->t->conn, watcher->id);
+
+ g_free(watcher->path);
+ g_free(watcher->srv);
+ g_free(watcher);
+}
+
static void destroy_char(gpointer user_data)
{
struct characteristic *c = user_data;
@@ -97,6 +117,9 @@ static void destroy_thermometer(gpointer user_data)
if (t->chars != NULL)
g_slist_free_full(t->chars, destroy_char);
+ if (t->fwatchers != NULL)
+ g_slist_free_full(t->fwatchers, destroy_watcher);
+
dbus_connection_unref(t->conn);
btd_device_unref(t->dev);
g_free(t->svc_range);
@@ -114,6 +137,19 @@ static gint cmp_device(gconstpointer a, gconstpointer b)
return -1;
}
+static gint cmp_watcher(gconstpointer a, gconstpointer b)
+{
+ const struct watcher *watcher = a;
+ const struct watcher *match = b;
+ int ret;
+
+ ret = g_strcmp0(watcher->srv, match->srv);
+ if (ret != 0)
+ return ret;
+
+ return g_strcmp0(watcher->path, match->path);
+}
+
static void change_property(struct thermometer *t, const gchar *name,
gpointer value) {
if (g_strcmp0(name, "Intermediate") == 0) {
@@ -410,12 +446,66 @@ static DBusMessage *set_property(DBusConnection *conn, DBusMessage *msg,
"Function not implemented.");
}
+static void enable_final_measurement(struct thermometer *t)
+{
+ /* TODO: enable final measurements */
+}
+
+static void watcher_exit(DBusConnection *conn, void *user_data)
+{
+ /* TODO: Watcher disconnected */
+}
+
+static struct watcher *find_watcher(struct thermometer *t, const gchar *sender,
+ const gchar *path)
+{
+ struct watcher *match;
+ GSList *l;
+
+ match = g_new0(struct watcher, 1);
+ match->srv = g_strdup(sender);
+ match->path = g_strdup(path);
+
+ l = g_slist_find_custom(t->fwatchers, match, cmp_watcher);
+ destroy_watcher(match);
+
+ if (l != NULL)
+ return l->data;
+
+ return NULL;
+}
+
static DBusMessage *register_watcher(DBusConnection *conn, DBusMessage *msg,
void *data)
{
- /* TODO: */
- return g_dbus_create_error(msg, ERROR_INTERFACE ".ThermometerError",
- "Function not implemented.");
+ const gchar *sender = dbus_message_get_sender(msg);
+ struct thermometer *t = data;
+ struct watcher *watcher;
+ gchar *path;
+
+ if (!dbus_message_get_args(msg, NULL, DBUS_TYPE_OBJECT_PATH, &path,
+ DBUS_TYPE_INVALID))
+ return btd_error_invalid_args(msg);
+
+ watcher = find_watcher(t, sender, path);
+ if (watcher != NULL)
+ return btd_error_already_exists(msg);
+
+ DBG("Thermometer watcher %s registered", path);
+
+ watcher = g_new0(struct watcher, 1);
+ watcher->srv = g_strdup(sender);
+ watcher->path = g_strdup(path);
+ watcher->t = t;
+ watcher->id = g_dbus_add_disconnect_watch(conn, sender, watcher_exit,
+ watcher, destroy_watcher);
+
+ if (g_slist_length(t->fwatchers) == 0)
+ enable_final_measurement(t);
+
+ t->fwatchers = g_slist_prepend(t->fwatchers, watcher);
+
+ return dbus_message_new_method_return(msg);
}
static DBusMessage *unregister_watcher(DBusConnection *conn, DBusMessage *msg,
--
1.7.6.1
^ permalink raw reply related
* [PATCH 4/8] Implement D-Bus unregister watcher function
From: Santiago Carot-Nemesio @ 2011-10-24 17:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
In-Reply-To: <1319475848-4171-4-git-send-email-sancane@gmail.com>
---
thermometer/thermometer.c | 30 +++++++++++++++++++++++++++---
1 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/thermometer/thermometer.c b/thermometer/thermometer.c
index 155b84a..6ff5da3 100644
--- a/thermometer/thermometer.c
+++ b/thermometer/thermometer.c
@@ -451,6 +451,11 @@ static void enable_final_measurement(struct thermometer *t)
/* TODO: enable final measurements */
}
+static void disable_final_measurement(struct thermometer *t)
+{
+ /* TODO: disable final measurements */
+}
+
static void watcher_exit(DBusConnection *conn, void *user_data)
{
/* TODO: Watcher disconnected */
@@ -511,9 +516,28 @@ static DBusMessage *register_watcher(DBusConnection *conn, DBusMessage *msg,
static DBusMessage *unregister_watcher(DBusConnection *conn, DBusMessage *msg,
void *data)
{
- /* TODO: */
- return g_dbus_create_error(msg, ERROR_INTERFACE ".ThermometerError",
- "Function not implemented.");
+ const gchar *sender = dbus_message_get_sender(msg);
+ struct thermometer *t = data;
+ struct watcher *watcher;
+ gchar *path;
+
+ if (!dbus_message_get_args(msg, NULL, DBUS_TYPE_OBJECT_PATH, &path,
+ DBUS_TYPE_INVALID))
+ return btd_error_invalid_args(msg);
+
+ watcher = find_watcher(t, sender, path);
+ if (watcher == NULL)
+ return btd_error_does_not_exist(msg);
+
+ DBG("Thermometer watcher %s unregistered", path);
+
+ t->fwatchers = g_slist_remove(t->fwatchers, watcher);
+ destroy_watcher(watcher);
+
+ if (g_slist_length(t->fwatchers) == 0)
+ disable_final_measurement(t);
+
+ return dbus_message_new_method_return(msg);
}
static DBusMessage *enable_intermediate(DBusConnection *conn, DBusMessage *msg,
--
1.7.6.1
^ permalink raw reply related
* [PATCH 5/8] Enable final measurement indications when first watcher is enabled
From: Santiago Carot-Nemesio @ 2011-10-24 17:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
In-Reply-To: <1319475848-4171-5-git-send-email-sancane@gmail.com>
---
thermometer/thermometer.c | 76 ++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 75 insertions(+), 1 deletions(-)
diff --git a/thermometer/thermometer.c b/thermometer/thermometer.c
index 6ff5da3..acb7747 100644
--- a/thermometer/thermometer.c
+++ b/thermometer/thermometer.c
@@ -150,6 +150,22 @@ static gint cmp_watcher(gconstpointer a, gconstpointer b)
return g_strcmp0(watcher->path, match->path);
}
+static gint cmp_char_uuid(gconstpointer a, gconstpointer b)
+{
+ const struct characteristic *ch = a;
+ const gchar *uuid = b;
+
+ return g_strcmp0(ch->attr.uuid, uuid);
+}
+
+static gint cmp_descriptor(gconstpointer a, gconstpointer b)
+{
+ const struct descriptor *desc = a;
+ const bt_uuid_t *uuid = b;
+
+ return bt_uuid_cmp(&desc->uuid, uuid);
+}
+
static void change_property(struct thermometer *t, const gchar *name,
gpointer value) {
if (g_strcmp0(name, "Intermediate") == 0) {
@@ -446,9 +462,67 @@ static DBusMessage *set_property(DBusConnection *conn, DBusMessage *msg,
"Function not implemented.");
}
+static struct characteristic *get_characteristic(struct thermometer *t,
+ const gchar *uuid)
+{
+ GSList *l;
+
+ l = g_slist_find_custom(t->chars, uuid, cmp_char_uuid);
+ if (l == NULL)
+ return NULL;
+
+ return l->data;
+}
+
+static struct descriptor *get_descriptor(struct characteristic *ch,
+ const bt_uuid_t *uuid)
+{
+ GSList *l;
+
+ l = g_slist_find_custom(ch->desc, uuid, cmp_descriptor);
+ if (l == NULL)
+ return NULL;
+
+ return l->data;
+}
+
+static void final_measurement_cb(guint8 status, const guint8 *pdu,
+ guint16 len, gpointer user_data)
+{
+ gchar *msg = user_data;
+
+ if (status != 0)
+ error("%s failed", msg);
+
+ g_free(msg);
+}
+
static void enable_final_measurement(struct thermometer *t)
{
- /* TODO: enable final measurements */
+ struct characteristic *ch;
+ struct descriptor *desc;
+ bt_uuid_t btuuid;
+ uint8_t atval[2];
+ gchar *msg;
+
+ ch = get_characteristic(t, TEMPERATURE_MEASUREMENT_UUID);
+ if (ch == NULL) {
+ DBG("Temperature measurement characteristic not found");
+ return;
+ }
+
+ bt_uuid16_create(&btuuid, GATT_CLIENT_CHARAC_CFG_UUID);
+ desc = get_descriptor(ch, &btuuid);
+ if (desc == NULL) {
+ DBG("Client characteristic configuration descriptor not found");
+ return;
+ }
+
+ atval[0] = 0x02;
+ atval[1] = 0x00;
+ msg = g_strdup("Enable final measurement");
+ gatt_write_char(t->attrib, desc->handle, atval, 2,
+ final_measurement_cb, msg);
}
static void disable_final_measurement(struct thermometer *t)
--
1.7.6.1
^ permalink raw reply related
* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Michael S. Tsirkin @ 2011-10-24 17:05 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Avi Kivity, Marcelo Tosatti, kvm
In-Reply-To: <4EA58DF4.2050100@siemens.com>
On Mon, Oct 24, 2011 at 06:10:28PM +0200, Jan Kiszka wrote:
> On 2011-10-24 18:05, Michael S. Tsirkin wrote:
> >> This is what I have in mind:
> >> - devices set PBA bit if MSI message cannot be sent due to mask (*)
> >> - core checks&clears PBA bit on unmask, injects message if bit was set
> >> - devices clear PBA bit if message reason is resolved before unmask (*)
> >
> > OK, but practically, when exactly does the device clear PBA?
>
> Consider a network adapter that signals messages in a RX ring: If the
> corresponding vector is masked while the guest empties the ring, I
> strongly assume that the device is supposed to take back the pending bit
> in that case so that there is no interrupt inject on a later vector
> unmask operation.
>
> Jan
Do you mean virtio here? Do you expect this optimization to give
a significant performance gain?
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
^ permalink raw reply
* [PATCH 6/8] Disable final measurements indication when last watcher is removed
From: Santiago Carot-Nemesio @ 2011-10-24 17:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
In-Reply-To: <1319475848-4171-6-git-send-email-sancane@gmail.com>
---
thermometer/thermometer.c | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/thermometer/thermometer.c b/thermometer/thermometer.c
index acb7747..835eca1 100644
--- a/thermometer/thermometer.c
+++ b/thermometer/thermometer.c
@@ -527,7 +527,30 @@ static void enable_final_measurement(struct thermometer *t)
static void disable_final_measurement(struct thermometer *t)
{
- /* TODO: disable final measurements */
+ struct characteristic *ch;
+ struct descriptor *desc;
+ bt_uuid_t btuuid;
+ uint8_t atval[2];
+ gchar *msg;
+
+ ch = get_characteristic(t, TEMPERATURE_MEASUREMENT_UUID);
+ if (ch == NULL) {
+ DBG("Temperature measurement characteristic not found");
+ return;
+ }
+
+ bt_uuid16_create(&btuuid, GATT_CLIENT_CHARAC_CFG_UUID);
+ desc = get_descriptor(ch, &btuuid);
+ if (desc == NULL) {
+ DBG("Client characteristic configuration descriptor not found");
+ return;
+ }
+
+ atval[0] = 0x00;
+ atval[1] = 0x00;
+ msg = g_strdup("Disable final measurement");
+ gatt_write_char(t->attrib, desc->handle, atval, 2,
+ final_measurement_cb, msg);
}
static void watcher_exit(DBusConnection *conn, void *user_data)
--
1.7.6.1
^ permalink raw reply related
* [PATCH 7/8] Manage watcher's disconnections from the bus
From: Santiago Carot-Nemesio @ 2011-10-24 17:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
In-Reply-To: <1319475848-4171-7-git-send-email-sancane@gmail.com>
---
thermometer/thermometer.c | 11 ++++++++++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/thermometer/thermometer.c b/thermometer/thermometer.c
index 835eca1..b71f589 100644
--- a/thermometer/thermometer.c
+++ b/thermometer/thermometer.c
@@ -555,7 +555,16 @@ static void disable_final_measurement(struct thermometer *t)
static void watcher_exit(DBusConnection *conn, void *user_data)
{
- /* TODO: Watcher disconnected */
+ struct watcher *watcher = user_data;
+ struct thermometer *t = watcher->t;
+
+ DBG("Thermometer watcher %s disconnected", watcher->path);
+
+ t->fwatchers = g_slist_remove(t->fwatchers, watcher);
+ watcher->id = 0;
+
+ if (g_slist_length(t->fwatchers) == 0)
+ disable_final_measurement(t);
}
static struct watcher *find_watcher(struct thermometer *t, const gchar *sender,
--
1.7.6.1
^ permalink raw reply related
* [PATCH 8/8] Implement D-Bus get properties function
From: Santiago Carot-Nemesio @ 2011-10-24 17:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
In-Reply-To: <1319475848-4171-8-git-send-email-sancane@gmail.com>
---
thermometer/thermometer.c | 32 +++++++++++++++++++++++++++++---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/thermometer/thermometer.c b/thermometer/thermometer.c
index b71f589..2c1b5b3 100644
--- a/thermometer/thermometer.c
+++ b/thermometer/thermometer.c
@@ -449,9 +449,35 @@ static void configure_thermometer_cb(GSList *characteristics, guint8 status,
static DBusMessage *get_properties(DBusConnection *conn, DBusMessage *msg,
void *data)
{
- /* TODO: */
- return g_dbus_create_error(msg, ERROR_INTERFACE ".ThermometerError",
- "Function not implemented.");
+ struct thermometer *t = data;
+ DBusMessageIter iter;
+ DBusMessageIter dict;
+ DBusMessage *reply;
+
+ reply = dbus_message_new_method_return(msg);
+ if (reply == NULL)
+ return NULL;
+
+ dbus_message_iter_init_append(reply, &iter);
+
+ dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY,
+ DBUS_DICT_ENTRY_BEGIN_CHAR_AS_STRING
+ DBUS_TYPE_STRING_AS_STRING DBUS_TYPE_VARIANT_AS_STRING
+ DBUS_DICT_ENTRY_END_CHAR_AS_STRING, &dict);
+
+ dict_append_entry(&dict, "Intermediate", DBUS_TYPE_BOOLEAN,
+ &t->intermediate);
+
+ if (t->has_interval) {
+ dict_append_entry(&dict, "Interval", DBUS_TYPE_UINT16,
+ &t->interval);
+ dict_append_entry(&dict, "Maximum", DBUS_TYPE_UINT16, &t->max);
+ dict_append_entry(&dict, "Minimum", DBUS_TYPE_UINT16, &t->min);
+ }
+
+ dbus_message_iter_close_container(&iter, &dict);
+
+ return reply;
}
static DBusMessage *set_property(DBusConnection *conn, DBusMessage *msg,
--
1.7.6.1
^ permalink raw reply related
* Re: Linux USB HID should ignore values outside Logical Minimum/Maximum range
From: Denilson Figueiredo de Sá @ 2011-10-24 17:04 UTC (permalink / raw)
To: Christoph Fritz; +Cc: linux-kernel, Jiri Kosina, linux-input, linux-usb
In-Reply-To: <1319476183.3210.12.camel@lovely>
On Mon, Oct 24, 2011 at 15:09, Christoph Fritz <chf.fritz@googlemail.com> wrote:
>
> * Note that input core does not clamp reported values to the
> * [minimum, maximum] limits, such task is left to userspace.
That means this is a bug in X.org, instead?
--
Denilson Figueiredo de Sá
Rio de Janeiro - Brasil
^ permalink raw reply
* RE: [PATCH] An argument for allowing applications to manually send RMPP packets if desired
From: Mike Heinz @ 2011-10-24 17:04 UTC (permalink / raw)
To: Hefty, Sean, Jason Gunthorpe
Cc: Roland Dreier, linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Todd Rimmer
In-Reply-To: <1828884A29C6694DAF28B7E6B8A8237316E5B763-P5GAC/sN6hmkrb+BlOpmy7fspsVTdybXVpNB7YpNyf8@public.gmane.org>
I'm not sure I understand the resistance to this patch. The patch does not break existing functionality and can demonstrably improve the performance of tools that can take advantage of it.
What's wrong with implementing this patch now and working on an improved mechanism for the future?
-----Original Message-----
From: Hefty, Sean [mailto:sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org]
Sent: Sunday, September 18, 2011 8:35 PM
To: Jason Gunthorpe; Mike Heinz
Cc: Roland Dreier; linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Todd Rimmer
Subject: RE: [PATCH] An argument for allowing applications to manually send RMPP packets if desired
> Ultimately I think the scalable/compatible answer is to move these
> RMPP work loads to a verbs QP and we need to have a user space RMPP
> implementation for that anyhow.
Many to one is never scalable. The applications simply cannot rely on every node querying the SA at the same time, especially for large amounts of data. And the overhead of MADs and RMPP is too high to be a useful solution to scaling.
This message and any attached documents contain information from QLogic Corporation or its wholly-owned subsidiaries that may be confidential. If you are not the intended recipient, you may not read, copy, distribute, or use this information. If you have received this transmission in error, please notify the sender immediately by reply e-mail and then delete this message.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 0/6] mfd: TPS65910: Bug fixes and enhancements
From: Kyle Manna @ 2011-10-24 17:05 UTC (permalink / raw)
To: linux-kernel, Samuel Ortiz
Cc: Jorge Eduardo Candelaria, Mark Brown, Liam Girdwood, Kyle Manna
This series of patches fixes a number of small problems with the TPS65910 that
were discovered on a custom board.
Additionally, the last patch enhances the platform to driver interface.
Changes from v1 based on feedback from Mark Brown:
* Drop the patch #5 from pervious series. It worked around a bug created by
another patch.
* Rework patch #6 completely.
[1] https://lkml.org/lkml/2011/10/19/182
[2] https://lkml.org/lkml/2011/10/19/191
Kyle Manna (6):
mfd: TPS65910: Handle non-existent devices
mfd: TPS65910: Add I2C slave address macros
mfd: TPS65910: Fix typo that clobbers genirq
mfd: TPS65910: Move linux/gpio.h include to header
mfd: TPS65910: Move regulator defs to header
mfd: TPS65910: Create an array for reg init data
drivers/mfd/tps65910.c | 23 +++++++++++++-------
drivers/regulator/tps65910-regulator.c | 37 ++++++++-----------------------
include/linux/mfd/tps65910.h | 37 +++++++++++++++++++++++++++++++-
3 files changed, 61 insertions(+), 36 deletions(-)
--
1.7.5.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
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.