> > Comments?
>
> I think it is not wise to generalize from no specific examples. You
> need at least two specific examples before you can generalize.
I'm being general because that is what I want this to be...
> In your case, I would like to know things such as:
> - what specific hardware you want to support (vendor, model)?
> - what is the specific interface the hardware uses (adaptor interface,
> software protocols)?
> - what is the specific application you want to use this hardware for?
I started to think about this because of a data aquistion board I want to
use, that plugs into the RS-232 port. In interface is fairly
straightforward, and easy to write. I am gonna reuse those routines in a
number of applications. So I figured, why can't I treat them just like any
other device, and possibly make this a loadable module.
> The things you have been talking about (modems and printers) do have
> standard interfaces in /dev, and the software that uses them (ppp,
> uucp, lpd) knows how to use it. So I don't the the problem.
The only reason ppp works is because you tell it how to dial the modem
using chat. Once the connection is established the current serial port
driver is fine. But to establish that connection require somebody who
knows the HAYES command set. I am saying that should be it's own driver.
Those new Winmodems I mentioned require more then just the HAYES set, and
that could be implemented there as well, if anyone wants to take the
trouble.
I can say much about lpd, especially with all the parport changes that
have occurred. Mainly I am thinking about serial ports, where you can plug
a number of different items with well-known (or not so well-known)
protocols.
--
Chris Arguin | "...All we had were Zeros and Ones -- And
Chris.Arguin@unh.edu | sometimes we didn't even have Ones."
+--------------+ - Dilbert, by Scott Adams
http://leonardo.sr.unh.edu/arguin/home.html |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu