[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [MiNT] Detecting dialup connections



> -----Original Message-----
> From: Guido Flohr [mailto:gufl0000@stud.uni-sb.de]
> Sent: Thursday, September 30, 1999 12:46 AM
> To: mint@fishpool.com
> Subject: Re: [MiNT] Detecting dialup connections
> 
> > posting from yesterday. Just renaming the devices won't 
> give you any details
> > about baudrates, handshake or other properties.
> 
> Yes, but there are situations where you don't need that 
> information but
> just want to know whether a device is a serial line or not.  

Well, you don't *need* to use all available information in all cases ;-)

Anyway, I don't mind using these names at all, but I don't think it's a good
idea to use them as default names in the kernel. Lots of (potential) users
won't be using a complex MiNTOS-setup anyway, but rather basic MiNT+AES to
multitask GEM-programs, have long filenames and basic networking. When these
users connect a modem to the port labeled "Modem 2" on the back of their
computer, they expect to find references to "Modem 2" when they set up
networking as well.

I'm working on Connexion 2 now (btw. the basics are now fully functional,
I'm using it every day. Does anybody want to do some testing for me?), and
one of my goals for this is that Connexion will handle the serialports
instead of pppd/chat. This includes configure, dial and hanging up. In order
to do this properly I need to know several things about the ports though:

1 A list of serial/modem-devices.
2 Supported baudrates.
3 Does it support hardware handshake?
4 Does it have DTR?

(1) is simple enough for now, I'm using your approach and scanning /dev for
modem*, serial* and tty*. I would prefer a more general approach though, but
this is OK for now.

(2) is much harder. You can use Fcntl() to set and get the current
baudrates, but there's no way to get a list of all supported baudrates.
Perhaps this is possible through the RSVF-cookie, but I will not use that
(I'd like to see HS-Modem dead and buried). Currently I just step through a
list of all supported baudrates I know of (from 19200 and upwards) and see
which are allowed on each port. It works, but if the port is already in use
but not locked it will have disastrous results...

(3) Impossible to detect.
(4) Ditto.

What I suggest is a set of opcodes for the following:

1. Is this device a serial device?
2. Retrieve a list of supported baudrates for this device (a simple
FIRST/NEXT approach would be fine).
3. Does this device support hardware handshake?
4. Does this device support DTR?
5. Retrieve the actual name for this device (i.e. the label on the physical
connector at the back of the computer).

I have not looked at the source yet so I don't know how difficult this is to
implement, but my guess is that it would be pretty easy. I can even give it
a try myself if we can agree upon what and how it should be implemented.

This might not be very usable from a shell-script, but it would make it a
lot easier to write more userfriendly, hardware-independent applications.

Jo Even Skarstein