--2iBwrppp/7QCDedR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2005.12.12 22:22:26 +0000, Iain Hibbert wrote:
| On Mon, 12 Dec 2005, Rui Paulo wrote:
|=20
| > On 2005.12.08 00:55:26 +0000, Iain Hibbert wrote:
| > |
| > | so, like I say - any comments welcomed..  this is not the end, or eve=
n the
| > | beginning of the end but its getting near the end of the beginning..
| >
| > Style:
|=20
| > 1) please use ANSI function declarations;
|=20
| on all functions? (grumble grumble..)

Yeah :-/

|=20
| > 2) and C99 uintXX_t types.
|=20
| I saw this mentioned someplace but didnt get around to it, yes its on my
| list (ok, done)
|=20
| > 3) break long lines where possible.
|=20
| Sure, there are some issues there but how long is too long in the modern
| world?  I use 160 char width xterm on ~5 year old laptop - 80 column
| terminals are surely a thing of the past?

/usr/share/misc/style says exactly what you need. :-)

|=20
| > 4) you seem to mix function name prefixes like "bt_" and
| > "bluetooth_". why?
|=20
| there is no real reason.
|=20
| bt_ functions (I think only 3 left) were legacy of a previous naming
| scheme that I did not yet change to hci_ (ok, done)

IC.

|=20
| bluetooth_ - I started this in shared lib but actually that is a whole
| ancillary mess and I'm not sure what is actually required.  I looked at
| other open source bluetooth projects naturally, BlueZ (linux) has a whole
| bunch of hci access functions that mostly get used for test programs but
| I'm not sure there is much call for HCI socket access library in reality
| and I found little point in rewriting code (theirs is GPL). FreeBSD
| provides a libbluetooth containing ntoa, aton, gethostbyname, getprotoent
| type functions and I suspect this will cater to our needs more and can be
| imported fairly directly but this has only become more important of late
| and I havent really looked at it as yet

I will try to do some research and see if I can come up with something
useful.

| (as you see when you look at my
| 'tools' - I just hardwire addresses when needed)

Imagine my surprise when I saw those cryptic numbers...

|=20
| > Microcode:
| > I think it would be better if we create a pkgsrc pkg for this.
|=20
| I think so too, but was unsure about the best way to import the firmware
| to the kernel - initially I had it compiling to a kernel module but
| changed it after I could not envisage a way to handle the following
| (admittedly unlikely) sequence:
|=20
| 1. load module
| 2. enable device (firmware is written, all is well)
| 3. unload module (its no longer needed, no worries)
| 4. power suspend (pcmcia device disabled, protocol does not need to know)
| 5. power restore - no firmware, akk!
|=20
| So I changed it such that #3 cannot happen..
|=20
| btw there is some firmware loading code for USB bluetooth dongles in
| ubtbcmfw.c that I did not find necessary to touch (it is not relevant to
| my hardware and should work as-is in any case) - seems to finger vnodes
| directly, is this a good idea? (I think USB attach code runs as a process
| so maybe its ok?)

I think at the moment the best way is to load the firmware using an
helper application like iwi(4) does.

| Is there a generic NetBSD 'load firmware' method I should look at in order
| to get firmware data into the kernel?

Unfortunately, no. We should come up with something since everytime a
new driver is added and it needs to load an external firmware someone
must reinvent the wheel.

		-- Rui Paulo

--2iBwrppp/7QCDedR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFDnfvKZPqyxs9FH4QRArl7AKC3KY+gCNlTgDZTq3+8PTzik8e+rwCdHKlK
RkF5hICaqudnbDAlOsR0yas=
=2HQ3
-----END PGP SIGNATURE-----

--2iBwrppp/7QCDedR--