hello darlings, please cc me because i am not subscribed to these lists. ta.
i am cross-posting because, whilst this is for a phone device, it's
actually a request for help on tty line discipline driver writing.
you may have heard of quite a bit of fuss over linux mobile phones,
recently, with the introduction of the Neo1973 from http://www.fic.com.tw and
the greenphone from http://www.trolltech.com - well, there are a few more
devices around which are tantalisingly close to being useable: the
htc universal, the htc sable (ipaq hw6915) and also the h6300 series i
understand is _already_ actually useable - it even has a gsm management
daemon (http://www.mulliner.org/h63xxlinux/feed/mplexd-0.1.tar.gz)
some of you may have also seen this:
http://www.handhelds.org/hypermail/kernel-discuss/19/1961.html
that's the background.
my question is this: having looked at the htc sable's K700 gsm module,
which talks some weird proprietary but easily-reverse-engineered protocol:
http://wiki.xda-developers.com/index.php?pagename=SablePhone
and having read harald's email, and basically gone 'cool!', and, having
then looked up 'tty line discipline' on google (_before_ writing
this...) and gone 'errr...' i was wondering:
could someone kindly advise me how to write a tty line discipline
driver?
i need to add one byte to the front (0x2) then a 2-byte length field,
then send the data that's written, then a 2-byte CRC-16 checksum, and, also,
on a read, to check that the first byte is a 0x2, then read the length
field, then that many bytes, and confirm the 2-byte CRC-16 checksum of
the data just read.
i've never encountered tty line discipline's before. which one is the
best example that i should start with to cut/paste? has anyone else
done this sort of thing before, such that i can start with their code
and do a minimum amount of work to get this done - quickly? can anyone
point me at userspace test example source code?
etc. etc.
... alternatively, i just... don't do this at all - i leave it to
userspace, which would be a hell of a lot easier, but would make
applications a pain, because they would need to use a library instead of
just opening /dev/ttySN just like any other phone app, to transfer AT
commands.
your kind assistance to further the free software community's standing
by successfully owning their own mobile phone is greatfully appreciated.
l.
--
lkcl.net - mad free software computer person, visionary and poet.
--
(removed arm-linux because I am not subscribed to it from this address,
don't know about hh)
On Sat, 25 Nov 2006, Luke Kenneth Casson Leighton wrote:
> and having read harald's email, and basically gone 'cool!', and, having
> then looked up 'tty line discipline' on google (_before_ writing
> this...) and gone 'errr...' i was wondering:
>
> could someone kindly advise me how to write a tty line discipline
> driver?
Well, this is what I came up with when I googled for it:
http://www.eros-os.org/design-notes/LineDiscDesign.html
http://www.linux.it/~rubini/docs/serial/serial.html
http://lwn.net/Articles/87662/
That's all I can help you with - didn't actually write any ldisc as it
wasn't the right solution for my problem.
HTH
Guennadi
---
Guennadi Liakhovetski
Hello Luke,
On Sat, Nov 25, 2006 at 04:06:14AM +0000, Luke Kenneth Casson Leighton wrote:
> i've never encountered tty line discipline's before. which one is the
> best example that i should start with to cut/paste?
The second link by Guennadi is very good.
You can think of ldiscs as a layer between the serial driver and the
application. You fill struct tty_ldisc and call tty_register_ldisc. The
app opens a tty device and calls the TIOCSETD ioctl on it. The app (the
"above") sees the usual driver API -- read, write, etc. Your routines
manipulate the data as you like; you call tty->driver.write to write to
the serial driver (the "below"). The serial driver can call your
routines to tell you that, e.g., it has data for you, etc. You may
convert the data, buffer it till the app calls your read, etc.
You can find many examples if you search for tty_register_ldisc in the
kernel tree. However, understanding how this works and reading
include/linux/tty_ldisc.h should be enough.
With kind regards,
Baurzhan.
P.S. I'm subscribed only to linux-arm-kernel.
> userspace, which would be a hell of a lot easier, but would make
> applications a pain, because they would need to use a library instead of
> just opening /dev/ttySN just like any other phone app, to transfer AT
> commands.
Like gnokii for example ?
You can do both - use a pty/tty pair to front the daemon
On Sat, Nov 25, 2006 at 11:08:26PM +0000, Alan wrote:
> > userspace, which would be a hell of a lot easier, but would make
> > applications a pain, because they would need to use a library instead of
> > just opening /dev/ttySN just like any other phone app, to transfer AT
> > commands.
>
> Like gnokii for example ?
>
> You can do both - use a pty/tty pair to front the daemon
heya alan,
thanks for responding.
what i was hoping was, like the motorola e680/a780 'mux_cli' driver,
which is an abortion-and-a-half, to be able to run gnokii or anything
like it _without_ having binary data in the /dev/ttySN datastream.
the way that harald plans to do this is to have a userspace daemon which
handles the actual serial data, and then hands it _back_ to kernelspace
(via ioctls?) for it to hand out to the relevant _dummy_ serial device.
one of these devices is what gnokii (or any other program) listens on, to
handle phone calls (ATH, ATA, ATDTNNNNN etc.). another is what you would
start pppd on - even at the same time as making a call, if you had UTMS
(i think that's right...) but you get the idea.
both harald's plan - and motorola's abortional 'mux_cli' driver -
achieve this. in motorola's case, it's SIXTEEN separate dummy serial
devices.
also, trolltech have already implemented the same thing, entirely in
userspace, and you connect to their daemon on TCP sockets on various
different ports, to get the different data (battery life, signal
strength, send/receive SMS etc.)
so there are many approaches. motorola went entirely kernelspace and
the driver is a fxxxxxg mess - 6,000 lines of unmaintainable shit.
trolltech (and, independently, the guys who did the h63xx port) went
entirely user-space. harald, for the openmoko neo1973 has gone for a
mixed approach, with a 'helper' daemon which does the hard work in a
sensible place - USERSPACE are you LISTENING motorola? :)
i _could_ wait for harald's work to make its way out of FIC, which
should be some time in january. i'd like to roughly know what i'm
doing before then :)
not least because harald's code certainly won't have support for e.g. the
htc universal's _awful_ audio management, part of which is done over
the serial link to the UTMS radio module! (there is device-switching
to the four separate speakers (!), volume control, bluetooth enabling
etc. it's horrendous)
that would need to have its own 'audio management' demuxed dummy serial
'port'.
plus, i don't believe that the eriksson k700 gsm radio module supports
TS07.10 (which is what is used on the Neo1973, the Greenphone, the
Motorola linux phones and many others). it's an entirely different - and proprietary - multiplexing protocol.
so i would have to do quite a bit of adaptation.
alternatively, someone else can buy one of these damn good - expensive -
pda/phones with gps built-in - and do it instead.
http://wiki.xda-developers.com/index.php?pagename=Ipaq6915
(i've about 90% finished the device-driver support: suspend/resume is
the only significant big task).
l.
p.s. if the linux kernel design could be compiled up (optionally, of
course, not as a total replacement redesign, of course, to avoid the
polarised bun-fights about which way is better) with options based
around the same principles that Gnu/Hurd was - message-passing and
used IPC and an RPC compiler to help turn IDL files into drivers -
then this would be an entirely moot point.
there would _be_ no awful/awkward kernelspace/userspace decisions like
this to make, as it would be possible to write a userspace daemon that
then 'republished' to the kernel the de-multiplexed serial ports.
but, i am sure you would agree: that's another looong story :)
--
--
lkcl.net - mad free software computer person, visionary and poet.
--
From: On Behalf Of Luke Kenneth Casson Leighton
> Subject: Re: tty line discipline driver advice sought, to do
> a 1-byte header and 2-byte CRC checksum on GSM data
drivers/char/n_tty.c
include/linux/tty_ldisc.h
include/linux/tty_flip.h
include/linux/tty.h
I can't see a reason why your code shouldn't be a perfect fit as an
ldisc.
..Stu