From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Tue, 28 Sep 93 00:13:11 EDT Subject: Linux-Development Digest #132 Linux-Development Digest #132, Volume #1 Tue, 28 Sep 93 00:13:11 EDT Contents: No smart serial boards??? (Russell Nelson) Re: No smart serial boards??? (Norbert J. Girardi) Re: Diffs for Motif (Mahesh Neelakanta) Re: Q: Anyone working on OS/2's HPFS for Linux? (Brett Person) Re: Whence 1.0? (Kevin Brown) Pascal compiler. (STEVEN J. KANGAS) Re: Linux Slowly Dying Off? + Lets make a game for Linux (Ian McCloghrie) Re: After Dark-like screensaver for Linux (James Winstead) Re: Linux Slowly Dying Off? + Lets make a game for Linux (Brandon S. Allbery) Re: Linux Slowly Dying Off? + Lets make a game for Linux (Damien Neil) Anything similiar to VMS/Schedule under Linux (smhenry@succeed.ee.vt.edu) Multi-port serial driver question (Eric Williams) Re: Multi-port serial driver question (David Jeske) Intelligent Serial Drivers becoming a reality (READ (David Jeske) ---------------------------------------------------------------------------- From: nelson@crynwr.com (Russell Nelson) Subject: No smart serial boards??? Date: 27 Sep 93 22:21:56 GMT In article <1993Sep26.190837.7308@pioneer.ci.net> richb@pioneer.ci.net writes: The way to convince hardware vendors to support Linux is to have a lot of people call them up saying "I run Linux and I would buy your product if you had a driver for it." Even better, go ahead and *order* the hardware, but put a clause on it "This order is void without a Linux driver for the foobarmumble". Do it even if you know damn well that they don't have a Linux driver. It lets them know exactly how much business they're losing because they don't have a LInux driver. -russ What canst *thou* say? Crynwr Software Crynwr Software sells packet driver support. 11 Grant St. 315-268-1925 Voice | LPF member - ask me about Potsdam, NY 13676 315-268-9201 FAX | the harm software patents do. ------------------------------ From: girardi@rniil.rni.sub.org (Norbert J. Girardi) Subject: Re: No smart serial boards??? Date: Mon, 27 Sep 1993 15:59:23 GMT Bill Heiser (bill@bhhome.ci.net) wrote: : In article <1993Sep26.190837.7308@pioneer.ci.net> richb@pioneer.ci.net (Rich Braun) writes: : > : >You can run 8 ports on a Linux box using the low-cost STB 4-Com. The : [...] : >cost is $110 per four-port card; comes with a quad 16550 chip, full : >modem and flow-control signals on all ports. If you want more than 8 : >ports, though, either you need more computers or you need a smart card : With the "standard" linux serial driver, even *one* line running : at 38400 (14.4 modem) uses quite a bit of CPU ... so I'd had to : think of running *8* lines on a non-intelligent board :-) *ONE* line at 38400 ( modem on V.32bis TUUCP 1.04 g(7,1024) ) uses 3.x % CPU on my noname 486DX33 with 8 MB and a 16555 uart. So, there should be no problem running 8 lines on this box. And do you really expect that all lines will be used for d/l or u/l simultaneously? The load from 8 remotely logged in users doing weird stuff on your machine is probably much higher than the down- or uploads. - Norbert -- SSSSSS SQUAREDANCE is FRIENDSHIP set to MUSIC. S QQSQQQ Norbert J. Girardi < girardi@rniil.rni.sub.org > SSSQSS Q Voice: +49 621 493417 (h) +49 621 381-3260 (w) QQQQQQ If you know how to REPAIR YOUR SQUARE :-) drop me a line ------------------------------ From: mahesh@cybernet.cse.fau.edu (Mahesh Neelakanta) Subject: Re: Diffs for Motif Date: Mon, 27 Sep 1993 22:40:30 GMT In article jmcalexa@iastate.edu (Jason M McAlexander) writes: >I have purchased the source code for Motif 1.2.2 and I am wanting to find >the diff files that will allow to [3~me to compile it. Any ideas. >I am not interisted in purchasing anohter set of binaries sence I ha >ave the source > libXm is pretty much generic and you should be able to compile a static version simply by using what is provided by OSF. Building a shared library is a little tricker. I recommend first getting the dll-tools packages (located in the GCC directory on tsx-11 or sunsite(?) and reading through the priciples of jump-tables, etc. I think the latest version is 2.8. Then, for compatibility with others who have motif shared libs, you should get the jump-tables for motif (located also in the GCC directory). This means that when you get libXm.so and libXm.sa, it will remain compatible with what is already out there. The tar file also contains the commands needed for the final build of the shared libs. Let me know if you have any questions. mahesh ============================================================================== Metro Link Incorporated. 2213 W. McNab Rd. Pompano Beach, Florida 33069 X11.5 and OSF/Motif for QNX, SVR3, SVR4.[012], SCO, Linux, UnixWare, LynxOS, AT&T, Venix, ISC, Solaris, Pyramid, SunOS Voice: +1.305.970.7353 Fax: +1.305.970.7351 Email: mahesh@metrolink.com ============================================================================== ------------------------------ From: person@plains.NoDak.edu (Brett Person) Subject: Re: Q: Anyone working on OS/2's HPFS for Linux? Date: Mon, 27 Sep 1993 23:11:40 GMT IBM hasn't released the specifications for HPFS. Microsoft did publish some information on it in 1989(?) but not enough to really do any real good. It would be better to write access routines for the various Linux filesystems under OS/2. I am thinking about working on that. -- Brett Person Guest Account North Dakota State University person@plains.nodak.edu || person@plains.bitnet ------------------------------ From: kevin@frobozz.sccsi.com (Kevin Brown) Subject: Re: Whence 1.0? Date: Mon, 27 Sep 1993 17:34:22 GMT In article <285l1d$4u6@senator-bedfellow.MIT.EDU> dthumim@athena.mit.edu (Daniel J Thumim) writes: > It seems that the last few patchlevel releases have not been any more >stable than previous ones. This is not good because people usually just >grab the latest kernel release, and if it's buggy that looks bad for >linux. Maybe we can split the kernel into two "releases"... one which >would have no new non-essential features added, but would only be debugged >until it's pretty stable and renamed 1.0, the other would be an "alpha" >kernel for those who prefer the bleeding edge of development, to work with >all the new features. Or, we can just work on stabilizing the current >release and *then* adding new features to 1.01 or whatever. There are >lots of new features waiting to go in all the time, and if we're always >putting in new features we can never concentrate on getting a debugged >release. I think it would be a very good thing if there was at least >one stable release out there that people could use, then it will allow >developers to play more with alpha kernels without messing up lots of >peoples' systems. > Just my two cents... I basically agree, though I think it would work best overall if done this way: There are two versions in each release. One is a bug fix version. One is a "new features" version. For each release, the "bug fix" version is the prior release's "new features" version with bug fixes, and the "new features" version is the current release's "bug fix" version with new features added. The reason for doing things that way is so that development moves ahead as quickly as possible, but a stable-as-possible version is always available. If done right, this could easily be managed by the configuration program at build-time. You just set it up to ask "Want new features?" and define NEW_FEATURES if the answer is "yes". Code that is new gets the appropriate #ifdef/#endif enclosures. Note that if something from the previous "new features" release isn't stable enough even after bug fixes, it can still be regarded as a "new feature" and treated as such. Sometimes it's not clear whether something is a bug fix or a new feature. In that case, it's a judgment call. Fortunately, we have someone managing the releases who is eminently competent and whose judgement we (obviously) trust: Linus. -- Kevin Brown kevin@frobozz.sccsi.com This is your .signature virus: < begin 644 .signature (9V]T8VAA(0K0z end > This is your .signature virus on drugs: <> Any questions? ------------------------------ From: sjkangas@major.cs.mtu.edu (STEVEN J. KANGAS) Subject: Pascal compiler. Date: 27 Sep 1993 23:35:37 GMT Has anyone ported a pascal compiler to linux yet? It seems like all the compilers (p4, etc.) I can find are all written in pascal. If I had a pascal compiler to compiler the compiler I wouldn't need a stupid compiler now would I? Any info would be appreciated. -- Steve Kangas sjkangas@major.cs.mtu.edu ------------------------------ From: imcclogh@cs.ucsd.edu (Ian McCloghrie) Crossposted-To: comp.os.linux.help,comp.os.linux.misc Subject: Re: Linux Slowly Dying Off? + Lets make a game for Linux Date: 27 Sep 93 21:49:06 GMT soup@penrij.UUCP (John R. Campbell) writes: >I really beleive that Linux _NEEDS_ a screen-saver like After-Dark's >TREK stuff, both for the normal console and X-Windows. As I understand it, X11R5 lacks the necessary hooks upon which one would hang a user-defined screensaver program like After Dark. I saw an announcement somewhere that X11R6 would correct this. -- /~> Ian McCloghrie | Commandant of Secret Police - Cal Animage Beta. < < /~\ |~\ |~> | | <~ | email: ian@ucsd.edu Net/2, USL 0! \_> \_/ |_/ |~\ |__| _> | Card Carrying Member, UCSD Secret Islandia Club ------------------------------ From: jwinstea@osiris.hmc.edu (James Winstead) Subject: Re: After Dark-like screensaver for Linux Reply-To: jwinstea@hmc.edu Date: Tue, 28 Sep 1993 01:37:19 GMT In article <54781@sdcc12.ucsd.edu> imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: soup@penrij.UUCP (John R. Campbell) writes: >I really beleive that Linux _NEEDS_ a screen-saver like After-Dark's >TREK stuff, both for the normal console and X-Windows. As I understand it, X11R5 lacks the necessary hooks upon which one would hang a user-defined screensaver program like After Dark. I saw an announcement somewhere that X11R6 would correct this. Not true at all. There already exists one, in fact - look for xscreensaver on ftp.x.org. It compiles quite cleanly on Linux, from what I remember (I compiled it some time ago). All that remains is for people to write nifty "modules" for xscreensaver to use. -- loveritablessencentipedependentalism+Jim Winstead Jr. (CSci '95)+WELCO andaterrificklengtherealityearguessy|Harvey Mudd College, WIBSTR|METOT mpathybridgenerationiceremonymphysic| jwinstea@hmc.edu |HEBAC alendareadvertisexpresshothoughthend+ +KHALL ------------------------------ From: bsa@kf8nh.wariat.org (Brandon S. Allbery) Subject: Re: Linux Slowly Dying Off? + Lets make a game for Linux Date: Tue, 28 Sep 1993 01:41:52 GMT In article <54781@sdcc12.ucsd.edu> imcclogh@cs.ucsd.edu (Ian McCloghrie) writes: >soup@penrij.UUCP (John R. Campbell) writes: > As I understand it, X11R5 lacks the necessary hooks upon which >one would hang a user-defined screensaver program like After Dark. >I saw an announcement somewhere that X11R6 would correct this. I've a pair of homebrew screen savers that prove that false. Both manipulate the colormap to do their dirty work, but an early version of one of them also included a simple full-screen-window saver for displays on which colormap manipulation doesn't work (e.g. monochrome or other StaticColor visuals). The logic for determining when to activate was borrowed from xautolock, a program which invokes xlock automatically to accomplish screen saving (the argument and resource handling, on the other hand, is muy own, and unlike xautolock it works properly :-) Moreover, I added some features (for example, user-defined hot regions, so you can specify "active corners" --- and a hotkey sequence to highligh the active regions, since they don't have to be corners). One is a true dimmer (reduces the colormap to some fraction of its initial intensity in as smooth a fashion as X allows, and returns it to normal the same way) and the other works like the "screen saver" in the old Atari 2600 units: random color changes. I suppose that, now that I've mentioned them, I ought to make them available... ++Brandon -- Brandon S. Allbery kf8nh@kf8nh.ampr.org bsa@kf8nh.wariat.org "MSDOS didn't get as bad as it is overnight -- it took over ten years of careful development." ---dmeggins@aix1.uottawa.ca ------------------------------ From: damien@b63519.student.cwru.edu (Damien Neil) Subject: Re: Linux Slowly Dying Off? + Lets make a game for Linux Date: 28 Sep 1993 01:55:58 GMT In article <54781@sdcc12.ucsd.edu>, Ian McCloghrie wrote: >soup@penrij.UUCP (John R. Campbell) writes: >>I really beleive that Linux _NEEDS_ a screen-saver like After-Dark's >>TREK stuff, both for the normal console and X-Windows. I doubt it. What's the point? Not that I have anything against a nice screen saver, but I don't want some huge thing that will bog down the machine while I'm telnetting to it. Now a nice, simple, Lorenz attractor; _that_ would be nice... :-) Anyway, Linux dosn't _need_ anything. > As I understand it, X11R5 lacks the necessary hooks upon which >one would hang a user-defined screensaver program like After Dark. >I saw an announcement somewhere that X11R6 would correct this. The hooks are not there, but it is possible. Take a look at xswarm; it can be set up as a screen saver. The docs say that it is a massive kluge, but it _is_ possible. Semi-related question: I once saw a Linux machine running X some program that drew a pattern of colored lines moving around in the background. Very nice. Anyone have an idea as to what that might have been? Currently I run xswarm in the root window to liven things up, but something with more pizazz would be nice... Followups to c.o.l.m. -- Damien Neil CMPS/EEAP "Until somebody debugs reality, the best damien@b63519.student.cwru.edu I can do is a quick patch here and there." dpn2@po.cwru.edu Case Western Reserve University - Erik Green ------------------------------ From: smhenry@succeed.ee.vt.edu Subject: Anything similiar to VMS/Schedule under Linux Date: Mon, 27 Sep 93 20:15:48 GMT+0200 Is there anything similiar to the VMS/Scheduler program under development for Linux? What I mean is a scheduler for a group of people, so they can schedule meetings and whatnot, I saw something like this on a VMS machine and was wondering if anyone was doing any work under Linux. -- Steve Henry - SUCCEED BBS Operator - succeed.ee.vt.edu SUCCEED - Southeastern University Coalition of Emerging Engineering Departments ------------------------------ From: wd6cmu@netcom.com (Eric Williams) Subject: Multi-port serial driver question Date: Tue, 28 Sep 1993 01:21:50 GMT I'm developing a driver for a Star Gate ACL, a "smart" 8-port serial board. Currently I'm doing this as a completely un-integrated driver with its own major device number, but I'm reaching the point where I can see the advantages of making it more intimate with serial.c and tty_io.c. The advantage is that the code for character echoing, cooked mode, ioctl, etc., would largely already be there. The disadvantage is that this board is *not* an assembly of 8250-descended chips, and it might involve adding multiple hooks into the existing code to break out the hardware-dependant parts. Any comments on the wisdom of doing this versus continuing on the path I'm on? Are these modules Holy Writ that thou must not desecrate? [On the subject of smart card price/availability, this board has its own 8088 and 64k of dual-ported RAM. I found it at the flea market for less than $100.] -- Eric Williams | Vincent: MC (B+S)t G+Y 1.0 Y L++ C+ T+ I+++ H+ S++ V+ F++ wd6cmu@netcom.com | Murphy: DS W+(B+R)t+R Y 1.1 Y L C+ T- I+++ H+ A+ F+ WD6CMU@WD6CMU.#NOCAL.CA.USA.NA ------------------------------ From: jeske@ux4.cso.uiuc.edu (David Jeske) Subject: Re: Multi-port serial driver question Date: 28 Sep 1993 03:27:47 GMT wd6cmu@netcom.com (Eric Williams) writes: >I'm developing a driver for a Star Gate ACL, a "smart" 8-port serial >board. Currently I'm doing this as a completely un-integrated driver >with its own major device number, but I'm reaching the point where I >can see the advantages of making it more intimate with serial.c and >tty_io.c. The advantage is that the code for character echoing, cooked >mode, ioctl, etc., would largely already be there. The disadvantage is >that this board is *not* an assembly of 8250-descended chips, and it >might involve adding multiple hooks into the existing code to break out >the hardware-dependant parts. Any comments on the wisdom of doing this >versus continuing on the path I'm on? Are these modules Holy Writ that >thou must not desecrate? We are in the middle stages of a intelligent serial board driver which will support the Star Gate ACL. It is below tty_io.c, and I have had some level of discussion about our driver's artecture with Linus. To Summarize: This is going to be a "Intelligent Serial Board Driver", capably of EASILY adding other intelligent serial boards. (and for that matter, non-intelligent boards). The minor numbers are DYNAMICALLY allocated when the "board configuration" program is Run. This is necessary because 1) intelligent board autodetection with "geometry" is very difficult, and 2) even if you detect it, you can't do anything with it anyhow because the "on-board" software needs to be loaded. An external "user-level" program will load the software onto the intelligent board. This would be run from an "rc" file. Currently we have finished a FEP/OS loader for The Digiboard Intelligent boards. This supports the PC/8i, PC/16i, PC/8e, and PC/16e. Our drivers will support these boards as well. The kernel drivers will support the Star Gate ACL, but I no longer have a Star Gate ACL, so it will require that I either get one.. or that I have someone to alpha test. (I have drivers which I wrote some time ago for the Star Gate board which are in use and working in my customers systems). These drivers are coming along nicely and should be in alpha withen 2 weeks. -- David Jeske(N9LCA)/CompEng Student at Univ of Ill at Cham-Urbana/NeXT Programmer CoCreator of the GTalk Chat Software System - online at (708)998-0008 Mail: jeske@ux4.cso.uiuc.edu NeXTMail: jeske@sumter.cso.uiuc.edu jeske@atlantis.eid.anl.gov Talk: jeske@armageddon.slip.uiuc.edu ------------------------------ From: jeske@ux4.cso.uiuc.edu (David Jeske) Subject: Intelligent Serial Drivers becoming a reality (READ Date: 28 Sep 1993 03:58:25 GMT I posted some time ago that I would be starting a intelligent serial driver project when I had the time. Well, with all the posts about Intelligent serial boards, even to bring up the option of writing your own. I have started our project. our (us being a friend of mine and I) Drivers are going to support the Digiboard PC/8i, PC/16i, PC/8e, and PC/16e initially. (With Star Gate ACL support to follow soon after) The drivers are written in a universal enough way that adding support for more intelligent (or non-intelligent) boards should be easy. A "user-level" program (run from the rc file) loads the "on-board" software onto the intelligent serial board (a different one will be written for each card supported), then a serial configuration program will tell the kernel driver 1) where the board is, and 2) how many ports it has. The minor numbers are dynamically allocated when each board is "added" to the configuration. We have a few things which will allow us to finish these drivers quickly 1) we have 100% working and stable versions of similar drivers under DOS which we wrote about a year ago (and which have been in use at several sites since then) 2) We already have the "Digiboard FEP/OS" loader completed. 3) I have already added ALL of the kernel stubs, and much of the read/write code. I have to do 2 major things: finish and test the interrupt routine, and add more ioctl() support. (at this point they will do little more than dial a modem) 4) We started 3 days ago. I expect it to be about 2 weeks before the Digiboard part of these drivers are in "releasable Alpha", give or take a few days. The StarGate ACL versions will be a bit longer since I no longer have the ACL board I used to write our DOS Star Gate drivers. (I should be able to get the kernel drivers working anyhow) BUT: we do NOT have enough information to write a "ACL loader" for the StarGate.. if anyone can do this, it would grately accelerate the StarGate support, feel free to email me if you would like source to the digiboard "FEP/OS" loader as example code. We will need a few StarGate driver "guinnea-pigs" in about 2 weeks.. so if your interested, email me. If not then I'll have to borrow one from somewhere. I am in communication with Linus about the design and integration of these drivers with the the Linux TTY support. It is our goal to make these drivers a well integrated part of the Linux kernel. NOTE: if you are working on digiboard drivers, and are thinking of emailing me asking about "how do you do XXX" or how do you do "YYY?". Please don't, when the drivers are released, I am going to include Documentation of how the Digiboard and StarGate boards work (in laymens terms), and you will be able to look at the source. One other thing which will need to be cleared away is the "distribution" of the Digiboard "FEP/OS" and the StarGate ACL on board-drivers. While it is true that you get these when you buy a serial board, it would be (in my opinion) more beneficial to distribute these (in their original form) WITH these drivers. I know that the Digiboard Drivers are available to anyone via the "DIGI-BBS", I'm not sure abOut the ACL drivers. If anyone has information about the distribution rights of the ACL (on-board) drivers, let me know. I would Like to be able to redistribute all of these "with permission". Of course I would love to support any multi-port serial boards so after the initial drivers are written, I'll find out if there are other boards which people would like drivers for. -- David Jeske(N9LCA)/CompEng Student at Univ of Ill at Cham-Urbana/NeXT Programmer CoCreator of the GTalk Chat Software System - online at (708)998-0008 Mail: jeske@ux4.cso.uiuc.edu NeXTMail: jeske@sumter.cso.uiuc.edu jeske@atlantis.eid.anl.gov Talk: jeske@armageddon.slip.uiuc.edu ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************