lkml.org 
[lkml]   [1999]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Please!! Help me to help us to use WinModems in Linux
Hi David.

> Personally, I'd prefer to see the winmodem drivers appear as
> userland daemons with the absolute minimum of kernel code
> included to allow them to be used. Reasons, in no particular
> order, include:

>> 1. Less kernel bloat. The tool will only be in memory when it's
>> actually in use, whereas kernel code is normally a permanent
>> feature of the memory map.

> Isn't that what modules and kmod are for?

In theory, yes, and I'd expect them to end up going that way, but for
initial development, I wouldn't recommend that course...

>> 2. Libraries. Userland tools can make full use of the standard
>> libraries such as libc which are not available to kernel code.

> I doubt that much of libc will prove to be useful for the
> purpose of driving Winmodems.

If what I've heard of WinModems is accurate, then "gcc -lm" will
probably be a big advantage...and I don't believe that's allowed in
the kernel...

>> 3. Easier development. In my experience, it's much easier to
>> debug userland stuff than kernel code.

> Depends on your viewpoint...

Will "Ex-Senior Programmer" help there?

> ...and your average caffeine intake.

NIL (I'm allergic to Caffeine, so have to avoid it).

> Either way - it's not a valid criterion on which to base such a
> choice - unless the technical merit of either possibility is so
> close that it makes sense just to choose the easy one.

I would see something like this being developed starting with the core
engine, which development doesn't even need the WinModme to be
present. That part could easily be developed as a userland tool with
the full userland debugging facilities.

Once THAT has been done, one can consider turning it into a kernel
module that talks to the WinModem, but there's no point doing that
beforehand...

> However, Winmodems are often likely to require some
> approximation of real-time response from the driver, and the
> best place to put that is in the kernel.

True, but get the core developed first, THEN look into that once you
know what you're talking about...

> There's a case for putting the AT command set emulation in
> user-space - in fact I'd go further and say there's a case for
> abolishing it altogether.

If there is, it's less than persuasive - IMHO doing so would be akin
to shooting oneself in the toes...

> Use ioctls for the various commands instead of AT-codes, and
> provide a library which opens and accesses the device on behalf
> of the client programs - cf. SANE and ESD.

My preference would be to have an ioctl interface for configuring the
driver and a userspace tool that intercepts AT sequences and turns
them into the appropriate ioctl's. That way, we reduce the likelihood
of commercial software houses turning away from Linux because of its
"non-standard" modem interface.

Best wishes from Riley.

+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:1.219 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site