[RFC] Introduce ports.
laforge at openmoko.org
Wed Aug 15 15:53:36 CEST 2007
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
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
> 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
- Harald Welte <laforge at openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the gsmd-devel