Hi Marcel,
Busy weekend. Remotely upgrading a Debian box, and upgrading its
hardware, having to take it one step at a time. I have started editing
the code to put in the style changes you recommended. Should be able to
get something to you tomorrow.
On Thu, 2004-12-02 at 12:35 +0100, Marcel Holtmann wrote:
> Hi Matthew,
>
> as a side note: Finally decide if you are going to discuss this in
> private with me or on the mailing list. Don't switch back and forth.
>
Probably bets to discuss this matter on bluez-devel.
> > At times the hidp_send_message gets called from within the context of
> > the running kernel thread when responding to received messages with
> > error handshakes, and you want to keep processing if possible until the
> > original hidp_schedule() after the transmission of messages. The aim is
> > to keep the execution flow as you planned it originally.
> >
> > Do you think a separate function is needed, without the schedule call at
> > the end?
>
> Actually a schedule should not harm in any way. If you think we really
> need it then I would prefer the same as a looked() versus __unlocked()
> functions.
Like you I want to keep things simple here, but I want to also avoid the
effects of giving up the processor to readily. Also I want to avoid the
complications of more locks. The reply messages are being sent inside
the global? Bluetooth HID lock. We have to be careful about the context
that this is all happening within. If you are that concerned about the
third function schedule parameter, I will create 2 separate control
message sending functions as they are only 3-4 lines long.
> > Thinking about how best to look after all the code and patching.
> > Putting all the BT code into a version control system here is looking to
> > be quite sensible to make the patching easier to handle. If we were not
> > patching core.c for the report mode support, this would be a lot easier
> > and cleaner.
>
> I don't see any need for it at the moment. Once we get your HIDP core
> stuff ready, I will try to merge it back mainline as soon as possible.
> Every change after that should be minimal.
>
This first patch is only phase 1 in a 3 stage process. Next 2 steps
will be just as big and invasive. After this probably half of the BT
HID may be changed around quite significantly. Please accept Debug code
code changes I make, as I need these to get debug code to compile for my
own use. The version control system is so that I can more easily keep
track of what I am doing.
As I write this, I am making changes you suggested to my code so that we
can get it merged. I still have a lot of this work on the machine in
Bangladesh to deal with for the next couple of nights till I can put it
on hold for a week or two before their final upgrade from woody to
sarge.
Best Regards,
Matthew Grant
Hi Matthew,
> > Actually a schedule should not harm in any way. If you think we really
> > need it then I would prefer the same as a looked() versus __unlocked()
> > functions.
>
> Like you I want to keep things simple here, but I want to also avoid the
> effects of giving up the processor to readily. Also I want to avoid the
> complications of more locks. The reply messages are being sent inside
> the global? Bluetooth HID lock. We have to be careful about the context
> that this is all happening within. If you are that concerned about the
> third function schedule parameter, I will create 2 separate control
> message sending functions as they are only 3-4 lines long.
maybe we have to move the hidp_schedule() call around. Don't duplicate
code even if they are only 3-4 lines long.
> > > Thinking about how best to look after all the code and patching.
> > > Putting all the BT code into a version control system here is looking to
> > > be quite sensible to make the patching easier to handle. If we were not
> > > patching core.c for the report mode support, this would be a lot easier
> > > and cleaner.
> >
> > I don't see any need for it at the moment. Once we get your HIDP core
> > stuff ready, I will try to merge it back mainline as soon as possible.
> > Every change after that should be minimal.
> >
>
> This first patch is only phase 1 in a 3 stage process. Next 2 steps
> will be just as big and invasive. After this probably half of the BT
> HID may be changed around quite significantly. Please accept Debug code
> code changes I make, as I need these to get debug code to compile for my
> own use. The version control system is so that I can more easily keep
> track of what I am doing.
The debug code is for the development stage. After the merge back we
remove it and leave only a minimal amount of debug code in there. That
is also the reason why no config option for it exists even if the define
looks like one.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel