BJ> What problem?  ttySX is the hardware rs-232 based serial ports.  

 >> Well, we suppose we only have one user logon per modem.. What will the 
 >> problem be then to use /dev/ttySX, to communicate thru?

 >> By point is why do we need a psedu terminal?

I believe you caught why later in my message -- ability to handle all nodes
of maximus exactly the same way..... (wether local, modem or telnet)....
 ...
 BJ> And I may be out of sync with Linux on one or 
 BJ> more technical issues.  I assume a fair amount of background based on 
 BJ> BSD flavored Unixes, but Linux is a System V clone.....

 >> Ok, maybe you should look a bit about handlingen modems in Linux (inbound 
 >> calls)...

When I have time.....

 >>> Oh i see, for example MBSE, have a mbtask manager there ensure that 
 >>> the processes whitch doesn't exist is beeing killed.

 BJ> Technically, the (running software)  processes still exist, but they 
 BJ> need to be killed because the physical connection has been broken or 
 BJ> disconnected.

 >> .. and i don't suppose mr. mgetty would like to do that.

Possible for (m)getty to handle it if (m)getty is able (or modified) to
send signals to child processes based on changes of hardware (status)
lines....

 >>> Linux is a sysv flavored clone.. But it's only about the initializing  
 >>> >> 
 >>> method?

 BJ> No.  There are some (at time subtle) differences between SysV and BSD 
 BJ> flavored Unix.  From memory, socket handling (at a low enough level) 
 BJ> *is* one of the areas where the differences surface.  

 >> Hmm.. ok, i've not been reading the whole Modern Operating Systems 
 >> (Adrew S Tannenbaum).

Mine is from experience, not text books.....

 BJ> We need similar capbility in the Unix / Linux port, but 
 BJ> getty may be the solution.  I think it can be (in a BSD flavored 
 BJ> unix) done via IOCtl calls.....  

 >> I wonder if mgetty exist in BSD systems too? How would these people else 
 >> could get a fidonet call :)

In older systems, getty was supplied as part of the operating system
routines.  Since mgetty is available with source code, it could be compiled
/ ported to other unix based systems....

 >>> Maybe it should be +++ATH+++..

 BJ> No!  This should be a configuration item.  Some BBS's change the +++ 
 BJ> sequence to a differnet character.  And the +++ sequence also 
 BJ> involves timing of a delay between certain characters.....

 >> But you're scure about the modem get's the initstring.

Modem initialization is only done if max is run in wait for caller mode, or
possibly after max issues a hang up of the modem....

 >>> That's right..

 BJ> After thinking about it, I have another solution to offer....  One 
 BJ> that leaves maximus started as a TCP/IP server /dameon.  Instead of 
 BJ> having (m)getty handling the modem, Max acts as a wait for caller for 
 BJ> the RS-232 based nodes, and could be implemented with the startup of 
 BJ> the TCP/IP demon.  The existing Maximus for OS/2, DOS and Win32 has 
 BJ> that as an option.  Unfortunately, this does not solve the Fidonet 
 BJ> front end mailer needs, and is why I don't use that option with 
 BJ> max.....

 >> ... the poor fidonet people :) 



 BJ> I haven't configured fidoconfig for either Linux or OS/2, so I 
 BJ> haven't tried to run the husky tools in either environment yet.  I 
 BJ> have contemplated it, but figured the current system wasn't broke in 
 BJ> this area (under OS/2).....  

 >> Ok, we need to write a Areafix program to Squish, so it would
work out  >> under Linux, i really don't think that the auther of
Sqafix would give 
 >> us the sources.. Did anyone ask him?

I don't think anyone has recently.  If Husky handles all of TICK's
functions, then getting Sqafix ported to a Linux / Unix platform should
solve most of the fidonet connectivity problems.  The areafix solutions
I've seen on some of the other linux based platforms have ignored some of
the older fidonet standards resulting in incompatibilities with raid /
allfix / etc....  :(

 >>> And i did some corrections in msgapi too..

 BJ> Interesting.  What needed correcting in the msgapi?  Was this the 
 BJ> Maximus msgapi, or the versions of the api previously ported to Linux 
 BJ> / Unix systsems for use by such things as the husky project?

 >> Maximus's msgapi, it didn't wrote the XMSG structure correctly (subject, 
 >> from, to, ftsc_data and so on). So i borrowed some code from the smapi.

Interesting.....

Take care.....

Bob Jones, 1:343/41


--- Maximus/2 3.01