Hi!
> Sorry to follow-up to my own post. A few people pointed out that
> v1.00 had some Makefile problems that prevented it from building.
> I've released v1.02, which should be fixed.
This should be forwared to linmodem list... Killing all those
binary-only modem drivers from kernel modules would be good
thing... Hmm, and maybe we can just hack telephony API over ltmodem
and be done with that. That would be good.
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
Pavel Machek writes:
>Hi!
>
>> Sorry to follow-up to my own post. A few people pointed out that
>> v1.00 had some Makefile problems that prevented it from building.
>> I've released v1.02, which should be fixed.
>
>This should be forwared to linmodem list... Killing all those
>binary-only modem drivers from kernel modules would be good
>thing... Hmm, and maybe we can just hack telephony API over ltmodem
>and be done with that. That would be good.
> Pavel
Hi,
Perhaps I don't understand how linmodems work to understand well
enough how FUSD would apply - do you talk to linmodems through the
serial driver? If so, sounds like a good application - but we might
still have the same problem with binary-only drivers as the
user-to-kernel message format used by FUSD may change over time.
(Indeed, it's already changing relative to v1.0 in response to
some of the mail I've gotten in the past few days.)
Best,
Jer
On Tue, Oct 02, 2001 at 03:37:53PM -0700, Jeremy Elson wrote:
> Pavel Machek writes:
> >Hi!
> >
> >> Sorry to follow-up to my own post. A few people pointed out that
> >> v1.00 had some Makefile problems that prevented it from building.
> >> I've released v1.02, which should be fixed.
> >
> >This should be forwared to linmodem list... Killing all those
> >binary-only modem drivers from kernel modules would be good
> >thing... Hmm, and maybe we can just hack telephony API over ltmodem
> >and be done with that. That would be good.
> > Pavel
>
> Hi,
>
> Perhaps I don't understand how linmodems work to understand well
> enough how FUSD would apply - do you talk to linmodems through the
> serial driver? If so, sounds like a good application - but we might
> still have the same problem with binary-only drivers as the
> user-to-kernel message format used by FUSD may change over time.
> (Indeed, it's already changing relative to v1.0 in response to
> some of the mail I've gotten in the past few days.)
>
That's not good.
If there's one part of the kernel API that shouldn't change, this (or
something like it) should be it...
Hi!
> >> Sorry to follow-up to my own post. A few people pointed out that
> >> v1.00 had some Makefile problems that prevented it from building.
> >> I've released v1.02, which should be fixed.
> >
> >This should be forwared to linmodem list... Killing all those
> >binary-only modem drivers from kernel modules would be good
> >thing... Hmm, and maybe we can just hack telephony API over ltmodem
> >and be done with that. That would be good.
[snip]
> Perhaps I don't understand how linmodems work to understand well
> enough how FUSD would apply - do you talk to linmodems through the
> serial driver? If so, sounds like a good application - but we might
Yep. And linmodem driver does signal processing, so it is big and
ugly. And up till now, it had to be in kernel. With your patches, such
drivers could be userspace (where they belong!). Of course, it would be
very good if your interface did not change...
Pavel
Pavel Machek <[email protected]> writes:
> Hi!
>
> > >> Sorry to follow-up to my own post. A few people pointed out that
> > >> v1.00 had some Makefile problems that prevented it from building.
> > >> I've released v1.02, which should be fixed.
> > >
> > >This should be forwared to linmodem list... Killing all those
> > >binary-only modem drivers from kernel modules would be good
> > >thing... Hmm, and maybe we can just hack telephony API over ltmodem
> > >and be done with that. That would be good.
> [snip]
> > Perhaps I don't understand how linmodems work to understand well
> > enough how FUSD would apply - do you talk to linmodems through the
> > serial driver? If so, sounds like a good application - but we might
>
> Yep. And linmodem driver does signal processing, so it is big and
> ugly. And up till now, it had to be in kernel. With your patches, such
> drivers could be userspace (where they belong!). Of course, it would be
> very good if your interface did not change...
I don't see how linmodem drivers apply. At least not at the low-level
because you actually have to driver the hardware, respond to interrupts
etc. On some of this I can see a driver split like there is for the video
card drivers, so the long running portitions don't have to be in the kernel.
I actually don't see what devices could be done in user space with
this context except possibly forwarding device calls across the
network.
Eric
On 7 Oct 2001, Eric W. Biederman wrote:
> Pavel Machek <[email protected]> writes:
> > Yep. And linmodem driver does signal processing, so it is big and
> > ugly. And up till now, it had to be in kernel. With your patches, such
> > drivers could be userspace (where they belong!). Of course, it would be
> > very good if your interface did not change...
> I don't see how linmodem drivers apply. At least not at the low-level
> because you actually have to driver the hardware, respond to interrupts
> etc. On some of this I can see a driver split like there is for the video
> card drivers, so the long running portitions don't have to be in the kernel.
My best guess for a Linux winmodem solution for Linux is three pieces:
The existing Lucent (and other) hardware work (by Pavel/Richard/Jamie/others?)
Rogier Wolff's user space serial driver code, and
A work called "modem" by a now-deceased scientist at SGI(IIRC). Alan
pointed me to the last piece. 'modem' handles up to 14.4k speed, and
supports some error correcting protocols we all remember from the BBS
days.
Just need someone to glue those pieces together... and you have a
winmodem driver with the proper portions in userspace, and the proper
portions in kernel space.
Jeff
On Monday 08 October 2001 04:37, Jeff Garzik wrote:
> A work called "modem" by a now-deceased scientist at SGI(IIRC). Alan
> pointed me to the last piece. 'modem' handles up to 14.4k speed, and
> supports some error correcting protocols we all remember from the BBS
> days.
BTW There was someone working on v.34, but the page hasn't been updated in
the last 18 months.. http://perso.enst.fr/~bellard/linmodem.html
> Just need someone to glue those pieces together... and you have a
> winmodem driver with the proper portions in userspace, and the proper
> portions in kernel space.
This is also important for USB modems. As Intel requests PC vendors to stop
including serial ports in 2002 and linux-compatible USB modems are quite hard
to find it will be really difficult to get an external modem for new
computers. Almost every new USB modem uses either the ST7554 or the Connexant
HCF chipset, and at least the ST7554 is controllerless.
bye...
On Fri, 5 Oct 2001, Pavel Machek wrote:
> Yep. And linmodem driver does signal processing, so it is big and
> ugly. And up till now, it had to be in kernel. With your patches, such
> drivers could be userspace (where they belong!). Of course, it would be
> very good if your interface did not change...
FUSD's user-kernel interface won't change spuriously, but it sometimes
will need to change as features are added. Some such changes are
already in the works.
The fact that FUSD provides a semi-stable binary interface for servicing
device-file callbacks isn't really FUSD's design goal as much as it is an
accidental side effect. Making a stable binary interface for kernel
device drivers is the objective of, say, UDI (I think). The purpose of
FUSD is just to be able to proxy the callbacks to userspace.
Best,
Jer
Hi!
> > Yep. And linmodem driver does signal processing, so it is big and
> > ugly. And up till now, it had to be in kernel. With your patches, such
> > drivers could be userspace (where they belong!). Of course, it would be
> > very good if your interface did not change...
>
> I don't see how linmodem drivers apply. At least not at the low-level
> because you actually have to driver the hardware, respond to interrupts
> etc. On some of this I can see a driver split like there is for the video
You don't actually need interrupts -- you *know* when next sample arrives.
And port io is completely fine with iopl() ;-).
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
> My best guess for a Linux winmodem solution for Linux is three pieces:
> The existing Lucent (and other) hardware work (by Pavel/Richard/Jamie/others?)
> Rogier Wolff's user space serial driver code, and
> A work called "modem" by a now-deceased scientist at SGI(IIRC). Alan
> pointed me to the last piece. 'modem' handles up to 14.4k speed, and
> supports some error correcting protocols we all remember from the BBS
> days.
>
> Just need someone to glue those pieces together... and you have a
> winmodem driver with the proper portions in userspace, and the proper
> portions in kernel space.
One of students here was/is working on the glue; it is non-trivial as
'modem' is obfuscated with coroutines.
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
"Pavel Machek" <[email protected]> writes:
> Hi!
>
> > > Yep. And linmodem driver does signal processing, so it is big and
> > > ugly. And up till now, it had to be in kernel. With your patches, such
> > > drivers could be userspace (where they belong!). Of course, it would be
> > > very good if your interface did not change...
> >
> > I don't see how linmodem drivers apply. At least not at the low-level
> > because you actually have to driver the hardware, respond to interrupts
> > etc. On some of this I can see a driver split like there is for the video
>
> You don't actually need interrupts -- you *know* when next sample arrives.
> And port io is completely fine with iopl() ;-).
But DMA? You are talking about what amounts to a sound card driver.
And since in the cases that burn cpu time you have to process raw
sound samples into modem data, you need to shift a fair amount of
data. inb and outb just don't have the bandwidth. So you need a
kernel side component that drives the hardware to some extent.
Additionally you still don't need a FUSD driver for that case. All
you need is to have is a ptty. Because that is what modem drivers
are now. And the ptty route has binary and source compatiblity
to multiple unix platforms.
Eric
Hi!
> > > > Yep. And linmodem driver does signal processing, so it is big and
> > > > ugly. And up till now, it had to be in kernel. With your patches, such
> > > > drivers could be userspace (where they belong!). Of course, it would be
> > > > very good if your interface did not change...
> > >
> > > I don't see how linmodem drivers apply. At least not at the low-level
> > > because you actually have to driver the hardware, respond to interrupts
> > > etc. On some of this I can see a driver split like there is for the video
> >
> > You don't actually need interrupts -- you *know* when next sample arrives.
> > And port io is completely fine with iopl() ;-).
>
> But DMA? You are talking about what amounts to a sound card driver.
> And since in the cases that burn cpu time you have to process raw
> sound samples into modem data, you need to shift a fair amount of
> data. inb and outb just don't have the bandwidth. So you need a
> kernel side component that drives the hardware to some extent.
You need to push 8kHz/16bit, that's 16 kilobytes per second. Or maybe
you can sample at 11kHz, getting 20 kilobytes per second. Comfortably
done with inb/outb.
> Additionally you still don't need a FUSD driver for that case. All
> you need is to have is a ptty. Because that is what modem drivers
> are now. And the ptty route has binary and source compatiblity
> to multiple unix platforms.
I do not think tty/pty pair does cut it for AT emulation. Can you
really emulate all neccessary features using pty/tty?
Pavel
--
Casualities in World Trade Center: 6453 dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
Pavel Machek wrote:
> > Additionally you still don't need a FUSD driver for that case. All
> > you need is to have is a ptty. Because that is what modem drivers
> > are now. And the ptty route has binary and source compatiblity
> > to multiple unix platforms.
>
> I do not think tty/pty pair does cut it for AT emulation. Can you
> really emulate all neccessary features using pty/tty?
Perhaps. Terminal modes & speeds & special lines and so on set on the
tty side can be seen on the pty side, although I think the pty is not
notified immediately so it has to poll if it wants to detect terminal
programs sending a BREAK signal and things like that.
I had a look at this about a year ago. I remember that a couple of
small changes to the pty/tty layer would have been very handy to improve
the quality of serial port emulation, and that might be the thing to do.
-- Jamie
Pavel Machek wrote:
> I do not think tty/pty pair does cut it for AT emulation. Can you
> really emulate all neccessary features using pty/tty?
Remember that if you go for a full user-space driver, you have to
duplicate the kernel's tty layer to emulate everything. For full
compatibility, that means emulating all the ancient serial and tty
ioctls properly including Linux-specific ones, SYSV-style ones,
BSD-style ones etc.
That's already been done _and_ tested in the kernel over the years.
While repeating that in user space is possible, I suspect that a pty/tty
interface would end up providing better compatibility (in practice) for
all the different, special and ancient terminal programs. In the cases
where pty/tty doesn't relay enough information to the pty side, we
should look at whether minor changes to the pty driver can fix that.
cheers,
-- Jamie