[RFC] Introduce ports.

[Harald Welte]

On Sat, Aug 11, 2007 at 06:03:40PM +0200, andrzej zaborowski wrote:

> > There is already a TS 07.10 implemetation in the kernel. See Harald
> > Welte's message:
> > http://lists.openmoko.org/pipermail/gsmd-devel/2007-July/000132.html
> >
> > It provides a TTY per DLC to userspace.
> >
> > This driver needs some more work though, it was ported from 2.4 for the
> > OpenEZX project. The EZX GSM-Modem deviates somewhat from TS 07.10, so
> > the differences should be factored out.
> 
> Ah, yes, now I see how it may be a better idea to do the multiplexing
> in the kernel for performance reasons. I didn't notice that bug #90
> was under "kernel" component rather than "gsmd" component.

no problem, sorry for the lack of documentation on this.

> I had a look at the OpenEZX version, it doesn't seem to deviate that
> much from TS 07.10 but it implements (and assumes, in far too many
> places) only features needed by that specific modem, e.g. only basic
> frame format, while Ti Calypso uses only the advanced frames, so this
> part can be taken from my patch, which is verified to work on the
> Neo1973. 

Yes, there is actually some extremely early, unfinished code in the
openmoko kernel svn quilt patchset (ts0710.patch) in which I
started to decouple the motorola-usb parts from the 07.10 layer and also
added a skeleton for a serial line discipline that can be attached onto
real ports.

> I would also like to see a possibility to open/close new DLCs
> through gsmd instead of having a hardcoded number of them, but I'm not
> sure what interface we would use (ioctl? on what node? maybe the DLC 0
> should also be exported to userspace and driven by gsmd, while the
> kernel would *only* wrap and unwrap data from ttys into frames).

my idea was to attach a line discipline to the main serial port.  That
line discipline can implement ioctl()s for DLC setup/teardown.
Actually, there is one more layer of abstraction: we attach the N_GSMMUX
line discipline and then tell it which muxer backend to use.  07.10 is
only one possible backend.  There are other, completely different
multiplex protocols, e.g. with wavecom modems.

> The struct gsmd_port idea is still a useful one I think. And I believe
> having an additional TS 07.10 implementation in gsmd is also quite
> crucial if gsmd has an ambition of being portable, although that's
> much lower priority.

It doesn't really have the ambition to be portable beyond linux (or
other operating systems implementing the same kernel-level gsm multiplex
API that we will implement).

Yes, sure, it is nice to have another multiplex implementation in
usersapace, especially since that one is already working, and not just a
wet dream.  But I'm not really decided if it's a good idea to give the
user that many different options. we don't want to be too confusing, do
we?

-- 
- Harald Welte <laforge at openmoko.org>          	        http://openmoko.org/
============================================================================
Software for the world's first truly open Free Software mobile phone