[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bluetooth-dev] Some questions on AXIS stack for Bluetooth
> I tried the release of Nov 2000, placed at
> And I am wondering on somethings, perha[s u guys would understand and
> explain things. I would appreciate it.
> 1. the stack can be compiled using kernel mode and user mode. Now the
> problem is that in user mode (BTD_USERSTACK), all the calls
> wake_up_interruptible(p) and interruptible_sleep_on are just
they are redefined to a sleep of 1 sec which is enough for most hci commands. If you would like to use semaphores instead please feel free to do it yourself, it is open source :) For our needs it is good enough (see below).
> There is no guarantee that after interruptible_sleep_on(), I
> would get the
> result. How can u expect that any serious development can be
> made this way?
The usermode stack is __only__ used for development and easy testing of basic stack functionalities and not meant for any 'any serious development'. (we will make this more clear in the next release README)
For example, when testing the stack on unplug fests we can very easily recompile/test/debug the stack and also call any function directly without having to go through ioctl calls. It is also much safer (doesn't crash the kernel...) to run when testing new code.
Another 'feature' is that you can run two stacks on the same computer without any hardware (using socket) (or let two stacks communicate over a lan without any HW). Very useful when testing _some_ things and you don't want to fiddle around with lots of modules and wires...
> 2. Another way for users to have full exposure to ur driver
> is to use IOCTL,
> but then again very few functionalities of bluetooth has been
> exposed there.
What do you suggest ?
In the latest stack which hopefully will be released today or next workday we now use a 'raw' interface from usermode which makes any command possible and removes the need for specific hci ioctls.
> 3. I can not help wondering why the programming model is not
> (event-driven) for the end users. I had a look at some APIs
> provided on
> Windows platform (Ericsson, DigiAnswer), and the one provided
> by Palm.com,
> and they all provide event-driven model.
Why would you prefer a different API ?
Axis Communications AB
> Looking forward to ur response
> To unsubscribe from this list: send the line "unsubscribe
> bluetooth-dev" in
> the body of a message to email@example.com
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to firstname.lastname@example.org