>> 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:
> something like a generic driver that simply allows userland
> drivers direct hardware access.
As I understand it, the 'hardware access' part of the driver consists
of it reading from or writing to specific IO ports or memory
addresses, and that much is already available...correct me if I'm
wrong here...
> Then the userland code could be just another process like you
> describe. The tricky bit would be tying this back into some
> sort of tty device in a generic/sane manner.
I would see that as being something like the following (which is a
pseudo-listing as they aren't set up here), which uses a range of
character device nodes that are currently unallocated, but other
node numbers would probably end up being allocated:
Q> $ cd /dev
Q> $ ls -lG modem wm*
Q> lrwxrwxrwx 1 root 3 Mar 7 1998 modem -> wm0
Q> crw------- 1 root 5, 32 May 5 1998 wm0
Q> crw------- 1 root 5, 33 Apr 7 16:59 wm1
Q> crw------- 1 root 5, 34 Apr 7 13:48 wm2
Q> crw------- 1 root 5, 35 Apr 7 13:48 wm3
Q> crw------- 1 root 5, 36 Apr 7 13:48 wm4
Q> crw------- 1 root 5, 37 Apr 7 13:03 wm5
Q> crw------- 1 root 5, 38 Apr 7 13:03 wm6
Q> crw------- 1 root 5, 39 May 5 1998 wm7
Q> $
When the WinModem driver was started up, it would be told which wmX
device to hook itself into, defaulting to the first unused one, and it
would hook itself in from that.
> 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.
> well some sort of raw i/o driver would be all that is necessary
> right? that should be small, and could be used for other things
> too. Do we allready have such a thing?
I believe the required code already exists.
>> 2. Libraries. Userland tools can make full use of the standard
>> libraries such as libc which are not available to kernel code.
> this gets back to the 'how to emulate a tty' question though, so
> as to not have to add code to libc or something to support these
> devices.
As far as the rest of the world is concerned, whether the modem is a
winmodem or a decent one should be totally transparent. For example,
referring to the above listing, minicom by default uses /dev/modem and
care's nothing whether that's a symlink to /dev/ttyS2 or /dev/wm0 as
it is above.
At worst, one would develop a libwinmodem library containing routines
common to most winmodem drivers, and the drivers would just be linked
against this library...
>> 3. Easier development. In my experience, it's much easier to
>> debug userland stuff than kernel code.
> sure is.
Nodz...
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/