Hi!

> > I believe I got the basics right. Separate motchat is the way to go.
> >
> > 1) protocol is packet-based, not character-based.
> >
> > 2) in AT you got
> >
> > > AT+TELL_ME_SOMETHING
> > < IT_IS_42
> > < OK
> >
> > while in motmdm it is:
> >
> > > U0005AT+TELL_ME
> > < U0005OK:IT_IS_42
> >
> > I believe that's why commands/responses are getting delayed in Tony's
> > case... AFAICT lot of complexity in atchat is collecting the multiple
> > lines, including handling stuff like
> >
> > IT_IS="Arbitrary
> > text including
> > OK
> > here"
> > OK
> >
> > We don't need or want any of that...
>
> Hmm just wondering about copying several thousand lines of gatchat
> code..

user@devuan:~/g/tui/d4$ wc -l /my/ofono/gatchat/motchat.c
1220 /my/ofono/gatchat/motchat.c
user@devuan:~/g/tui/d4$ wc -l /my/ofono/gatchat/motchat.h
209 /my/ofono/gatchat/motchat.h

> What's keeping us from just implementing motmdm_receive() and
> motmdm_send_command() directly in motorolamodem.c like we're doing in
> the GNSS kernel driver for example?
>
> I guess my point is: Do we really want to keep any of this AT stuff
> around at all?

Perhaps not :-). Feel free to trim down motchat.c more, just try not
to break it.

But ... notice that we don't have separate thread, and we should not
block the main thread. .. that are the rules of glib-based code, which
makes code tricky/ugly, and full of callbacks :-(.

You can't just do write("AT+PLEASE_DO_THIS_COMMAND_FOR_ME"). You need
to test if the device is ready for writing... But yes, buffering could
be simplified, because we know we are writing full packets. (And we
need to write full packets, motchat may not get that right).

So yes, this probably can be improved, but be aware of the dragons,
and be warned that this is in some aspects more low level than kernel
(due to lack of threads).

Best regards,
                                    Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html