btuart API change - rfc

[Iain Hibbert <plunky%rya-online.net@localhost>]

Hi,

I've been discussing some changes I would like to make to the btuart(4)
driver with kiyohara@ who wrote it and we have failed to agree on the
correctness of one fairly major change.  So, we have come to tech-kern for
arbitration.

As background, the btuart(4) driver is a tty line discipline, that
provides a way for the bluetooth stack to interface with certain
devices that manifest as a serial interface (either via standard RS232
port or an internal UART) much like the way slip(4) and ppp(4) interface
to the network stack, and possibly related to irframetty(4) that provides
IR device access (though, there is no in-kernel IrDA stack)

The way that Kiyohara wrote this driver, all the initialisation for
supported chips is carried out inside the kernel; the application that
activates the device must open the /dev/ttyXX and set the speed and
the line discipline, then set some parameters and activate it, eg:

        ioctl(com, TIOCSLINED, line);
        ioctl(com, BTUART_INITSPEED, &init_speed);
        ioctl(com, BTUART_HCITYPE, &type);
        ioctl(com, BTUART_START);

I find this to be onerous because
    - it is complex (code and API)
    - must update kernel to handle new device types
    - user program and kernel must be in sync (HCITYPE must be known to both)
    - hardware is behind a tty, we do not deal with the chip
    - not easy to debug failed initialisations

and I would like to move the initialisation of devices to the userland
program, which would handle setting a device into the known state *before*
activating the line discipline.

My point is that slip(4) and ppp(4) do not deal with tty or modem init,
or dialing the connection; that is handled how I think it should be handled.

Kiyohara points to irframetty(4) which also knows how to set line speed on
different devices but I'm not sure thats the same, since it may be that the
IrDA stack needs to change settings (I'm not sure how that works, really :)

Things we agreed on were that btuartd should be btattach to follow naming
conventions (it handles btuart(4) and bcsp(4) line disciplines) and that it
should be single-shot rather than the multiple line daemon that it is now
(C is IMHO not best suited to parsing config files, and if one daemon handles
many lines it is not easily possible to start and stop each separately)

Rather than a diff which would be messy, I have posted a shar file of the
reduced driver and new btattach program at

        http://www.netbsd.org/~plunky/btattach.4.shar

If anybody would care to take a look and give opinions on the [proposed]
API change I would apreciate it, thanks!

regards,
iain

(btuart(4) is only in -current so far, so no compat need be considered)