On Mon, 12 Dec 2005, Rui Paulo wrote:

> On 2005.12.08 00:55:26 +0000, Iain Hibbert wrote:
> |
> | so, like I say - any comments welcomed..  this is not the end, or even the
> | beginning of the end but its getting near the end of the beginning..
>
> Style:

> 1) please use ANSI function declarations;

on all functions? (grumble grumble..)

> 2) and C99 uintXX_t types.

I saw this mentioned someplace but didnt get around to it, yes its on my
list (ok, done)

> 3) break long lines where possible.

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?

> 4) you seem to mix function name prefixes like "bt_" and
> "bluetooth_". why?

there is no real reason.

bt_ functions (I think only 3 left) were legacy of a previous naming
scheme that I did not yet change to hci_ (ok, done)

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 (as you see when you look at my
'tools' - I just hardwire addresses when needed)

> Microcode:
> I think it would be better if we create a pkgsrc pkg for this.

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:

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!

So I changed it such that #3 cannot happen..

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?)

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

iain