Re: btuart API change - rfc

[christos%astron.com@localhost (Christos Zoulas)]

In article <1207414153.037208.1496.nullmailer%galant.ukfsn.org@localhost>,
Iain Hibbert  <plunky%rya-online.net@localhost> wrote:
>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)

While I prefer for device drivers to live completely in the kernel and
not do depend on userland programs to participate in device configuration,
I think that in this case the btattach way proposed here is cleaner than
the magic ioctls and easier to extend.

christos